Java Industry News
Open Source Java? - Why on Earth Would I Want That?
Sun gave reporters an update on the planned release of Java and its associated tools under an open source license
May. 23, 2007 09:00 PM
Alan Williamson's Blog
(August 17, 2006) - This week at LinuxWorld Laurie Tolson gave reporters an update on the planned release of Java and its associated tools under an open source license. By the end of the year, javac and the hot spot compiler will be released. The precise license details haven't yet been announced yet - that is the part of the equation they are wrestling with the most since there are components within the JDK that aren't theirs to open source. Politics and licenses aside, let us look at what this means for the humble Java developer, the troops in the trenches churning out code daily.
The first and natural concern is of course the dreading forking. Forking is when two people make two different changes to the same code base resulting in an incompatibility with one another. This scenario is Java armageddon - the one we all fear the most. We have a small taste of this already when writing code for different versions of the JDK, but if you are careful and not always use the cutting edge API's then you're code will still happily run on legacy JVMs. A good rule of thumb is to write for at least 2 versions behind the current release. So with 1.6 about to make an appearance, you can safely play with the new tools with the 1.4 API. Naturally this depends on your own application environment so its not a hard and fast rule by any stretch.
Another area where you may already be maintaining different code bases depending on the production system is with Microsoft J#. Microsoft only got the rights up to Java 1.1 and if you code your Java application to that 1.1 API, then code will happily run on both the Microsoft .net and Java JVM runtimes. So writing for different target systems is something developers have been use to for many years now, so should we be worried about the dreaded fork?
The problems faced so far by developers have largely been down to API changes, relying on methods/classes that may or may not exist on the production system. These are relatively easy to spot with a good development environment. For example, you can easily tell Eclipse to compile for only 1.4 with it doing all the checking to make sure you haven't lapsed into a 1.5 call. But forking here could be more sinister than simple API misalignment. What if you call a method and it does something completely different than you expect?
Sadly this isn't anything new to someone who has been coding Enterprise applications that are designed to run over a wide range of application servers. Sure there is a standard JavaEE API that exists, but that is no assurance that your application will run fine on all application servers, as the interpretation of some of the API calls is down to the owner of the application server. Even the standard, relatively small, Servlet API can produce many different results depending on the servlet container.
By forking the underlying JVM we now have a much greater potential for code to either not work or behave differently. We are putting more responsibility onto the Java developer to either target a given runtime and code exclusively for that, or even worse, forcing them to test with different runtimes across different platforms. Their job could get a whole lot messier.
We already have different runtimes available to us though, with BEA JRockit and IBM's runtime and these problems don't seem to have raised their ugly head. The difference here is that these companies had to license the technology from Sun and be made to pass a stringent certification process before launching to the public at large. In an open source world this certification restriction wouldn't be there. People could easily hack the JDK to do something different and have no requirements to meet any test criteria. They could simply use it as is.
A possible way around this would be to have Sun release the certification tools so other implementations of the JDK could be tested against it. This may not necessarily test any new functionality that a developer added to the JDK, but it would make sure they didn't break anything that was suppose to work in the process. This is far more important for wide acceptance.
Okay, so let us look at this from a point of view of hope.
What benefits can the developer get from an open source Java? Take a look at the JDK bug parade
. Take a look at the Top25 bugs
. Here is the biggest gain for the developer.
Some of the Top25 date back as far as 1999. That is nearly 7 years a request/bug has sat there. In an open source world, the 130 odd people that have voted to have low-level network support
within Java could now potentially build it themselves and contribute it back to the core branch for potential inclusion. At the moment, they have to wait until Sun dedicates coding resources to it. It is obviously clear that Sun hasn't found the time in the last 7 years to address some of these! Time to let someone else try.
There are many small bugs floating around that the community could easily tackle. Many of the bugs/features are pure Java implementations with no native code required. This opens up the potential number of contributors even further. There could be a huge development boost to the community with a much faster release cycle.
Sun has to manage this carefully. If they can be shown to be responsible stewards of the code allowing contributions from others then the reason to fork the JVM will not be as great. Why should you create your own JVM if your change can be incorporated into the main release and made available to you. If you are that desparate for it and can't wait for a release, you can use the latest build from SVN/CVS. Naturally I do not see Sun being the only committer on Java, they would merely be a member of a large group of committers.
On the whole I support the open sourcing of Java and its associated tools. Sun is right to take this slowly and consult with all parties
. They only get one shot at this and once the genie is out of the bottle, it won't be wanting to go back in.
Reader Feedback: Page 1 of 1
Steve Bell commented on 18 Aug 2006
The fear of a fork is a little on the paranoid side. If somebody decides to fork Java and create an incompatible version they cannot call it Java. The trademark is not being released.
Al Forbes commented on 18 Aug 2006
Very good article. Just two comments:
1. The latest JDK's are extremely stable and well tested. They are only difficult to use if you rely on an application server or IDE to support the latest features.
2. Your article linked to the RFE's instead of the bugs. The correct link is:
The Cherbin commented on 18 Aug 2006
Another waste of an article. Its nonsense, and it just gives these boring so called programmers something to talk about when their chatting about their precious little java code. Fling the big words like "Open Source" along with Java and maybe even more unknowning people will start to use it, and even pay for a class, buy one of the 1000 books written in 50 different languages too.
JDJ News Desk commented on 17 Aug 2006
This week at LinuxWorld Laurie Tolson gave reporters an update on the planned release of Java and its associated tools under an open source license. By the end of the year, javac and the hot spot compiler will be released. The precise license details haven't yet been announced yet - that is the part of the equation they are wrestling with the most since there are components within the JDK that aren't theirs to open source. Politics and licenses aside, let us look at what this means for the humble Java developer, the troops in the trenches churning out code daily.
Subscribe to the World's Most Powerful Newsletters
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an over...
Feb. 17, 2018 01:45 PM EST Reads: 7,677
"As we've gone out into the public cloud we've seen that over time we may have lost a few things - w...
Feb. 17, 2018 12:45 PM EST Reads: 4,933
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
Feb. 17, 2018 09:00 AM EST Reads: 3,259
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know ...
Feb. 17, 2018 04:00 AM EST Reads: 3,077
"Since we launched LinuxONE we learned a lot from our customers. More than anything what they respon...
Feb. 17, 2018 02:15 AM EST Reads: 2,576
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every ...
Feb. 17, 2018 01:15 AM EST Reads: 2,842
Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is...
Feb. 16, 2018 10:15 PM EST Reads: 7,312
The need for greater agility and scalability necessitated the digital transformation in the form of ...
Feb. 16, 2018 08:45 PM EST Reads: 711
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting ch...
Feb. 16, 2018 11:00 AM EST Reads: 2,214
While some developers care passionately about how data centers and clouds are architected, for most,...
Feb. 16, 2018 10:00 AM EST Reads: 2,620
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily ...
Feb. 15, 2018 02:00 PM EST Reads: 2,618
We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy hig...
Feb. 15, 2018 01:00 PM EST Reads: 545
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection...
Feb. 15, 2018 01:00 PM EST Reads: 3,710
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis too...
Feb. 15, 2018 12:15 PM EST Reads: 3,264
"Cloud4U builds software services that help people build DevOps platforms for cloud-based software a...
Feb. 15, 2018 11:45 AM EST Reads: 2,561
The question before companies today is not whether to become intelligent, it’s a question of how and...
Feb. 15, 2018 07:45 AM EST Reads: 3,658
Kubernetes is an open source system for automating deployment, scaling, and management of containeri...
Feb. 14, 2018 01:00 PM EST Reads: 3,100
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...
Feb. 14, 2018 12:30 PM EST Reads: 5,810
As many know, the first generation of Cloud Management Platform (CMP) solutions were designed for ma...
Feb. 14, 2018 12:00 AM EST Reads: 3,943
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...
Feb. 13, 2018 11:00 PM EST Reads: 3,112