I am looking at using HttpsConfigurator, HttpsServer, and HttpContext in the com.sun.net package. Additionally, part of my project requirement is to use OpenJDK.
I am coding in Eclipse, which will not auto import anything from the com.sun.net package, because it is considered 'forbidden'. After enabling forbidden packages, I can get everything working, building and running. My question, what is considered safe to use in OpenJDK? I am under the impression that it is just the java.* and javax.* packages.
I downloaded the OpenJDK 7 source, and I see that com.sun.net is part of the source, which implies that my assumption might be incorrect. I haven't had any luck googling yet, and I was hoping one the experts here can fill in the missing pieces.
In recap, what is considered safe to use in OpenJDK? Why would Eclipse label com.sun.net as 'forbidden'?
Thanks!
Countless documents -- books, articles, tutorials, official JDK documentation -- have explained that the com.sun.* packages are implementation details, subject to change or removal at any time; they are not intended for user programs. They are not portable, not reliably present, and possibly not as robust as actual API classes. In general, if the JDK documentation bundle contains Javadoc for it, it's intended for your use; otherwise not.
Related
I have been trying to scan my code by using SonarQube + FindBugs + FindSecBugs plugins.
The idea is to detect vulnerabilities in the code, and as it says in the github project subject, it works with scala https://github.com/find-sec-bugs/find-sec-bugs
I have installed the plugin as the documentation says, and tried a few scans but nothing related to vulnerabilities in scala is coming up.
So, in order to figure out if the code was really good or there was a misconfiguration on my SonarQube settings, I went to http://find-sec-bugs.github.io/bugs.htm, I took one of the examples (Potential Path Traversal), inserted the example code and I ran the scanner again. It was not found.
The rule (Security - Potential Path Traversal (file read)) is activated in the Quality Profile, and despite it is a Java profile, it is assigned to the project, since the code in the mentioned example is Scala.
I noticed that all the rules coming from find-sec-bugs are java ones, so I'm wondering if they don't work on scala or there is something else I can do to make it work.
Thanks in advance, and let me know if you need any extra information, I'd be glad to provide you.
Looks like the main reason for that to happen is that Scala bug patterns are explicitly excluded for some reasons:
Their are plenty of limitation with the SonarQube architecture regarding the multi-language support.
It is closely tie to the sonar-source plugin design.
Language can't have the same extension (https://jira.sonarsource.com/browse/MMF-672)
Repository can't contains rule that apply to multiple languages. (If you would have Scala only code, the Java core rules would not be enable unless you have one Java file present)
Sensor are couple to the language definition (depends on the most popular plugin that declares it).
etc, etc..
Source: https://github.com/spotbugs/sonar-findbugs/issues/108#issuecomment-305909652
All the exclusions can be seen here: https://github.com/spotbugs/sonar-findbugs/commit/526ca6b29fae2684f86b1deba074a4be8a05b67e
Particularly, for Scala:
static exclusions = ['CUSTOM_INJECTION',
'SCALA_SENSITIVE_DATA_EXPOSURE',
'SCALA_PLAY_SSRF',
'SCALA_XSS_TWIRL',
'SCALA_XSS_MVC_API',
'SCALA_PATH_TRAVERSAL_IN',
'SCALA_COMMAND_INJECTION',
"SCALA_SQL_INJECTION_SLICK",
"SCALA_SQL_INJECTION_ANORM",
"PREDICTABLE_RANDOM_SCALA"]
We have gtk 2.16.6 in our library, and there are a lot of other libraries that appear to be dependencies (pango 1.24.0, glib 2.20), but I'm looking for a readme file or something to show the lawyers that states that it uses those libraries. The reason we are doing this is for our product that we are distributing, we need to identify and state what licenses we are using. The worst license will prevail for something that uses other licenses/libraries. This is the only way I can see getting around the lawyer asking us what exactly gtk is explicitly doing with all of the other libraries.
I tried searching online but I don't see info on dependencies for gtk. I opened the library, and there are some readme files that say something about the release of a version of glib causing an error, but it doesn't really say it's a dependency.
Well the best method to finding the real libraries linked would be to use ldd on each shared object built. Gio and GdkPixbuf do have a few libraries that can be loaded at runtime which would be a bit trickier to track down. A look at what various distributions list as deps would be helpful or possibly just finding the paths libraries look for external modules in and going back to ldd for them.
I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.
Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?
Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.
IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.
I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.
Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.
Edit:
We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.
What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.
First, you can easily compile/run your program just by checking out your repository.
Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.
Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.
I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.
The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.
I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.