Tags: OpenJDK
In
Irritation and Open Source Java David Gilbert discusses something he thinks is an irritation about open source Java.
Namely .. If, say, the Eclipse team were to: I wonder if the Eclipse Foundation could (if they wanted) fork Java by creating a runtime that is derived from Sun's code (and so runs all 1.5 / 1.6 applications just as well as "official" Java) but includes some compelling new features not endorsed by the Java Community Process (JCP). .. his conclusion is that if the Eclipse team were to do that they wouldn't be able to call the result "Java".
Weeell... that's not quite true. And I think it's a misconception I see often enough that I want to spend a bit of time discussing it.
Currently there's several steps involved in having a Java implementation which you can call Java. For instance you have to pass the TCK conformance tests (JCK) to demonstrate compatibility. There's also some kind of license or other business agreement that I think is required to be able to use the Java trademarks. I don't know the business end of it very well, so I'm going to concentrate on the conformance end which I know a little better.
The Java platform specification includes the java.* and javax.* packages in Java, the JNI classes, and some other API's. The Java platform specification does not specify the classes in any 3rd party toolkit. Not Hibernate, nor Rome, nor JDOM, nor SWT, etc are specified in the platform specification. Obviously.
The question isn't whether the Eclipse project could distribute a Java implementation that has SWT in it ... it's whether any 3rd party can distribute a Java implementation that has additions bundled into rt.jar. Eclipse adding SWT is simply one example. Another example might be Ubuntu distributing a Java with the java-gnome bindings built into rt.jar.
The purpose of the platform specification is so that an application can be taken to "any" Java VM and run. The platform specification is a minimum set of features that are required. Features can be added to a JRE/JDK and still be compatible with the platform specification. But if features are removed from a JRE/JDK then it isn't conformant with the platform specification.
Okay, getting back to this hypothetical situation with Eclipse. One might expect this hypothetical JRE from Eclipse to include SWT and drop AWT/Swing. If AWT/Swing were dropped then that would not be compatible with the platform specification, and could not be called Java. However, if the hypothetical JRE from Eclipse were to include both AWT/Swing and SWT, that would continue to be compatible and could be called "Java". (So long as they fulfill other business requirements around licensing the trademark, and so long as they pass the JCK)
The Eclipse team might well be wanting to compete with Sun anyway. And if you think about the history of writings about open source ... go back to the GNU Emacs distribution and the various text files Richard Stallman included therein. He laid out the business model of how one earns money when the software is given away for free. It's somewhat counter-intuitive .. if you give the software away for free, how can you earn a living? Stallman's answer was "support and services". In other words, the open source world becomes a competition for who can provide the best support and services. People will pay for support and services, and increasingly government regulations require business critical applications to have support and service contracts in place.
Clearly some other organization could set up a support and service operation using the Java source base .. and if that other organization were to do a good enough job of innovation and support and services, and outdo Sun, then perhaps Sun would lose control over the destiny of Java. The "other organization" might not be able to continue calling their product "Java" but maybe that doesn't matter if they have a good enough marketing organization.
I can think of a couple examples of this ... XEmacs versus GNU Emacs is a dusty example from the depths of history, where Lucid and Sun could not get agreement with the GNU foundation over some changes to Emacs and hence they ended up forking to create XEmacs. More recently there was a fallingout among Mambo developers, some of whom charged off in their own direction to create Joomla.
Source:
weblogs.java.net
