For which surprises do I have to prepare myself if I switch from Sun JDK to OpenJDK?
https://stackoverflow.com/questions/2236661
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
If I'd switch from Sun JDK to OpenJDK which surprises do I have to prepare myself for?
What does frequently go wrong and how difficult can this be?
Of course, each and every application can have its individual problems, but I'm looking for classes of problems, something many people already have struggled with when switching JDKs.
Solution
It is unlikely that anything will go wrong with OpenJDK. It is considered 100% compatible by now. But I think it is good to know what parts had to be rewritten and therefore are not using the same code as the SunJDK.
The Wikipedia entry has a good overview of this:
As of May 2008, the only part of the Class library that remains proprietary and closed-source (4% as of May 2007 for OpenJDK 7, and less than 1% as of May 2008 and OpenJDK 6) is the SNMP implementation.
Since the first May 2007 release, Sun Microsystems, with the help of the community, has released as free and open-source software or replaced with free and open-source alternatives almost all the encumbered code:
All the audio engine code, including the software synthesizer, has been released as Open-source. The closed-source software synthesizer has been replaced by a new synthesizer developed specifically for OpenJDK called Gervill,
All cryptography classes used in the Class library have been released as Open-source,
The code that scales and rasterizes fonts has been replaced by FreeType
The native color management system has been replaced by LittleCMS. There is a pluggable layer in the JDK, so that the commercial version can use the old color management system and OpenJDK can use LittleCMS.
The anti-aliasing graphics rasterizer code has been replaced by the Open-sourced Pisces renderer used in the phoneME project. This code is fully functional, but still needs some performance enhancements,
The JavaScript plugin has been open-sourced (the Rhino JavaScript engine itself was open-sourced from the beginning).
OTHER TIPS
As I know fonts will look garbled, Sun had to remove original ones from OpenJDK since they are not 'open source' and JVM will use some default which are not so nice...
Since OpenJDK is a Sun project, based on the original Java source, I wouldn't expect many problems. The only area where things can break is the code which had to be replaced (because it couldn't be released under the GPL) or changes because of new features (but those should be pretty much the same as in the official JDK).
Use an OpenJDK build known to pass the TCK to minimize the surprises.
Some of the swing UI's did not match up entirely (metal had paddings that were off just aenough to notice). Note that this was 8 months ago.
OpenJDK (IcedTea) applets under linux are a MAJOR PAIN. I'm struggling with remote debugging a piece of rather rusty code for couple of hours already. Official documentation on how to attach to an applet in a browser simply does not work for me. There's no java console by default, BTW. I'm seriously considering replicating the applet config and using JDK built-in applet viewer instead of trying to debug the browser-hosted JVM.
UPD: I am not quite sure that OpenJDK does not have a browser plugin itself. Maybe this changed recently.
OpenJDK is more secure than the Oracle binaries because of IcedTea.
