Why should I use the Oracle JDK over the OpenJDK, or vice-versa? [closed]

I recently purchased a new laptop and made my old one into a Linux box, running Ubuntu. I started to download the tools that I need, and I'm getting my Java development environment set up now. I have a choice between the Sun Java 6 JDK and the OpenJDK.

What advantages does one have over the other? Can I run both side by side?

Views: 54

Reply to This

Replies to This Discussion

What advantages does one have over the other?

OpenJDK works rather well, is very stable and is the default VM on many GNU/Linux distros (because the code is under GPL I guess). In my opinion there aren't much differences from a technical (~99% of their code is shared1) and from an end user point of view but, if you don't mind using proprietary software, I'd still go for Oracle JDK. It's not that OpenJDK is not stable (IcedTea is the JVM of RHEL and RedHat is supporting it) but you might face little more bugs with OpenJDK than with Sun JDK (as the former is moving faster). Some packages will require OpenJDK though (even if Oracle JDK is installed, I don't know, this must be a bug). If you want to play with Java 7, OpenJDK is nice. About Java 7, note that JDK7 and OpenJDK7 will have (nearly) identical code base.

See Oracle’s JDK7, OpenJDK & IcedTea: Disambiguation for more details. There are actually plenty of other interesting thread over the Internet, for example this one (read all pages). Googling on IcedTea should bring very interesting results too.

Can I run both side by side?

Yes, you can and you can tell the system which one to use by default (for the Java software).

To get a list of the installed JDK

$ sudo update-java-alternatives -l 

To set a new as default one (at the system level)

$ sudo update-java-alternatives -s /span>jname> 

I have both of them installed to do some testing from time to time and use java-6-sun as default.

OpenJDK will give you new features faster, Sun JDK should give you more stability.

There have been a lot of good answers by a lot of much better programmers than I. However as a part-developer part-sysadmin of Java Applications I can offer one further suggestion.

While the other answers are very important to consider, regarding the choice between OpenJDK and Oracle JDK primarily, my decision is generally about 90% dependent on.... what the core developers of the target platform or software are using.

That sounds a bit simplified, but it really does work well.

For example, we have a client with a ERB/Glassfish/Java EE/netbeans platform. Initially I tried running that on a CentOS machine with OpenJDK 1.6. However there were continual problems and cases requiring submitting bug reports etc. It turns out that the fixes are already in the Oracle patches, but won't make it to the CentOS/RHEL repos for 6 months.

I have had an opposite experience with tomcat on CentOS, in that the CentOS/Apache/MySQL/Tomcat stack is a very well tested set of packages in the RHEL ecosystem. This also applies to Ubuntu ecosystem now they are shipping OpenJDK.

I originally learned my lesson on this one, with trying to run the configuration management tool Chef, by using the RPM packages from the CentOS repos, and they were always 6 months behind. It turns out that the developers focused on releasing to rubygems first, and once I realised I was just making it hard for myself, it went much more smoothly.

There are loads of little things that add up to make the case, for example just submitting a bugfix, its might be hard to get a core-developer to take a look at it, because they don't have a box with OpenJDK installed...

Oracle JDK 7 is built from OpenJDK, quote "Moving to OpenJDK as the official Java SE 7 Reference Implementation":

If it is just a private project it does not matter really, I guess.

But if you develop for a public/commercial project ask the operations what the official supported environment is. Even if the environments (devel vs. production) are 99% identical you should always use the official supported and tested version.

In a real case the used jre vendor was not communicated correctly (ibm vs. sun). We developed/tested our software with sun. One day on production a jre-bug popped up, which never happened on development environment, because different jre-versions were used. aargh!

I have been doing some CS research where the program I am working on is written mostly in C but uses the JNI for some new tasks (eventually the whole program will be translated into java) Anyway... I was doing test runs on two different machines and one was completing the tests and the other was getting stuck. It turns out that the difference was the first machine had sun-jdk and the other had open-jdk. When I installed sun-jdk on the machine, it was able to complete the tests. So somewhere there is a difference between the two. Possibly in the way they implemented the JNI? If thats the case it likely wouldn't effect a normal user.

With openjdk, you have the sound mixer working : i.e you won't have error like "the current audio device is currently in use" : with SunJdk, if your java program tries to play a sound while another program is already playing, it won't work, which is lame :/

Basic approach to the problem should consider - what would be the path going forward.

The SunJDK is going to be more-and-more proprietary code going forward.

And OpenJDK makes a lot more sense - to be true to the Java spirit that Sun Microsystems [not Oracle] had espoused right from the beginning

Besides with OpenJDK you are assured of portability - because of known standardised API's

With SunJDK - no one knows where its headed.

Just my two cents...

I found recently that there are differences in PrintWriter implementation when used with multithreading: try creating a PrintWriter object and use it in different threads, I was using format and checkError methods, PrintWriter methods are threadsafe AFAIK (on an invididual call basis); Sun JDK appeared to be correct in implementation in the sense that I saw the effects by way of mingled output (multiple calls were made to above methods to produce output, only individual calls are threadsafe unless the full loop producing output is synchronized explicitly). Open JDK however had no issues - in my tests, the threads had their outputs cleanly separated, so it would appear to protect in case of 'goofy' code it appears.

Just one example. This might fall within the 1% code people are saying is different, I haven't checked the two JDKs' code myself yet actually.

In my project am using Sun JDK, earlier we had Open JDK but it gave font issues. So we moved to Sun JDK.

One big difference is that the documentation is different. I don't know if Sun released the docs in a license that is compatible with OpenJDK, but they are using (from my experience) the GNU classpath documentation, which is nowhere near as good.

Sun has great documentation, and you can still use their docs if you want to use OpenJDK, but that could cause confusion if OpenJDK has implemented it differently.

Reply to Discussion

RSS

Oracle Jobs in US

© 2022   Created by Maisam Agha.   Powered by

Badges  |  Report an Issue  |  Terms of Service