sun


Why are there many JRE implementations?


I was wondering..There is Sun's JRE, IBM's JRE, BEA's JRE, Oracle's JRE and some more less know JREs in the market.
Why is there so many JRE implementations? Does the fact that Sun opened the Java platforms mean that there will be one open JRE / JDK? Or are we going towards what happened with Linux and its many distributions ?
Why is there more than one C compiler? Why is there more than one implementation of Ruby? Different implementations allow different teams to explore different possibilities for optimisation etc. For instance, I'm pretty sure that at one point the IBM JRE was much faster than the Sun one for floating point. Other implementations may have special features for pre-compilation etc.
As for whether OpenJDK will reduce the variety available - it's hard to say. I'm pleased that the variety exists though - competition like this helps everyone.
Sun supports Solaris, Windows and Linux with its JREs and JDKs. Other vendors wanted their platforms to be supported so they wrote their own, usually based on technology licensed from Sun. That's why Apple developed a JVM, they wanted support for OS X. Open Source developers wanted Java to be supported on BSD and on Linux platforms other than x86 and Sparc (e.g. PowerPC). IBM wanted a JVM on z/OS and AIX and, since they were developing it anyway, they may as well release it for Windows and Linux.
Is Oracle's JRE just JRockit, which they acquired with BEA?
Because they serve different needs? Sun's JREs are the main ones for Windows and Linux for the desktop and many server applications. BEA's has some nice manageability features, and improved performance for a lot of cases (at the cost of higher startup times and higher memory consumption). IBM's is theoretically faster as well, and is tuned to run their app servers well. That gets it a few users on Linux and Windows, but it is mostly popular on non-Sun supported platforms (IBM AIX, OS400, etc).
I believe that the "Oracle JRE" you are referring to is just a rebranded BEA JRE from after the BEA purchase.
In the end, they are all compatible with the Sun TCK, and generally share much code (Java libraries, Swing, in some cases Hotspot) as well as an extremely high degree of compatibility. In practice, they are at least as compatible with each other as the various versions of Windows (Vista vs. Server, etc).
OpenJDK will likely gain popularity among Linux users due to being completely open source, however, it is unlikely to replace Sun's JDK in the immediate future on non-Linux platforms for various reasons (free font rendering is slightly weaker than the closed source variant, etc).
And then, of course, Sun doesn't release the VM for the Mac, as Apple manages that themselves.
So, is this like the situation with Linux distributions? I don't really think so, for a couple of reasons:
Testing - Each of these passes a TCK to insure compatibility with the standard. Linux distributions make very little effort to maintain similar compatibility.
Versioning - Java 1.6 == Sun 1.6 == IBM 1.6 == Any Java 1.6. Linux has very little standardization in terms of versioning to insure compatibility across releases. LSB tries to do this, but is not yet there fully.
Consistency - With the exception of odd platforms for which the standard jdk tools are unlikely to work in the "standard" way (eg, AS/400), each feels exactly the same. Each has the same "javac" and other tools to conform to Sun's standards. In practice, they are vastly more similar than Linux distros.
So, I guess my answer is that they are different because of need, and the great flexibility offered by the platform. But its nothing like the kind of incompatible environment that we see in the Linux world.
BEA made one because it needed specific performance enhancements for its WebLogic server. Other's have for the same reasons. They all think they can do it a little better, and they all need something special from the JRE. Sun has specs for the JRE, and all of the ones I know about conform to it. So any Java or Scala code you write should still work.
Oh, and the openJDK will not solve everyone's problems, so there will still be multiple proprietary JRES.
There are many JRE's because there are many different collections of requirements by people using Java. Server usages will often use JRockit previously BEA, now Oracle), as it is specifically tuned for server usage. The Sun offerings are tuned to work work pretty well for any use, but the 3rd party offerings can be tuned to work better than Sun's JRE in specific or niche usages.
This is different from Linux and its many distributions due to the guarantees that are placed by Sun's licensing requirements for 3rd party Java implementations. Barrings bugs, you pretty much know how all Java JREs will operate. The specifications are pretty tight.
I don't think that opening the JDK means that the number of JRE's will remain the same or decrease. If anything, based on community experience of open source software (Linux, for instance?), we'll probably have even more JREs.
And why not? Competition is a good thing.
Java was designed to begin with as a standard specification that anyone was free to implement. The goal was to offload some work from Sun to make it more universal (since OS/platform vendors can write their own JREs), but more importantly, to allow competition and thus improved performance.
To a great degree this model worked fairly well. A lot of the newer garbage collection techniques were initially developed, tried, and tested on research-oriented JREs. So have some other optimizations (e.g., IBM Researched used to maintain a separate JRE). Other vendors created implementations that were optimized for a particular architecture.
I agree that at some point, perhaps when Java became less popular due to MS .NET or due to Sun's own problems, advances stopped being integrated from implementation to implementation, which does create a mess for users.
If you in doubt just use the standard Java VM from Sun/Oracle.
Remember Sun did not completely Open Source all of Java, some parts are stilled closed.
Primary Reasons for Third-Party VM Implementations
- Supporting non-sun supported platforms
- Closed Platforms (Mac, theirs gives better OS integration so you can't complain.
- Licencing Constraints (Can't be distributed by distributions)
- OS Distributer Policy (Fedora only provides free and open software)
- Simply trying to compete and make a better Java VM
- Optimization/Extending for a Platform (Android)
Another reason besides addressing different performance needs is Sun's strategy and business model for Java. If another implementation wants to use the Java branding, they have to be certified and licensed by Sun. Sun wants to see Java used everywhere and realizes they cannot write an implementation that covers every possible need. By promoting different implementations of the Java specifications, Sun encourages the growth of the community and helps ensure Java's long term survival.
There are other JREs such as the OpenJDK which is open source.
There are also J2ME versions which run on mobile devices and things such a blu-ray players.
Some JRE implementations are tailored to suit the embedded systems market -- where memory size is sometimes more important than raw speed.
Even Sun has at least two versions of the JRE -- a server version that is better performing but uses more memory and takes more time to start up, and a client version that is optimized to run smaller applications.

Related Links

Sun Metro WebServices with Spring
Where can I find old versions of the JDK and JRE? [closed]
Anyone tried submitting hs_err files to Sun?
Why are there many JRE implementations?

Categories

HOME
phantom-dsl
r-googlesheets
jax-ws
gluon-mobile
minecraft-forge
plist
naivebayes
radgridview
dynatrace
plink
android-intent
coin3d
powershell-v5.0
intershop
vuejs
video-editing
wolframalpha
google-container-registry
charles
xunit
interbase
jaws
boost-asio
recurring-events
fstream
carriage-return
servicestack-text
sharepoint-workflow
nohup
mongoose-schema
chef-solo
facebook-social-plugins
procfile
mesosphere
custom-font
qtranslate
avx
pocketsphinx-android
latin
greatest-n-per-group
signalr.client
x-tag
mapinfo
installshield-2010
udpclient
qiime
thread-sleep
pushbots
jparsec
highland.js
spring-retry
toran-proxy
django-urls
vacuum
fits
delayed-execution
raygun
personalization
mintty
android-framework
file-not-found
vbe
git-repo
windows-embedded-standard
jquery-1.9
android-icons
windows-98
tree-balancing
web-farm
boost-signals
lambdaj
agility.js
flex-mobile
tournament
strsep
mtu
aspmenu
ifilter

Resources

Encrypt Message