David Herron's Blog

Re: Irritation and Open Source Java

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.

Comments

• I think IBM and BEA should follow suit, and open up their source code as well. There is no plausible reason for them to keep it closed, now that Sun is doing it, too, and it would help them avoid beeing regarded at as strong on open letters, but weak on execution. ;)

  The power of nightmares around future scenarios revoles a lot around which particular licensee may decide to go mad, and fracture the platform. I think there is a lot to be said for IBM and BEA doing as they preached, and killing the incentive to play lock-in games with implementations of the platform.

  Posted by: robilad on August 22, 2006 at 04:32 AM

• Now you've done it David... You got me thinking again ;-)
  -JohnR

  Posted by: johnreynolds on August 22, 2006 at 10:33 AM

• Good clarifications, David. However, I think the current frustration around the definition of the platform specification--e.g. what libraries compose it--is not as much about adding optional libraries (like SWT) but about what it currently includes. I know of no one who has told me they are grateful that there are CORBA interfaces in the JRE, and many who have questioned it. So you do have some who want to have somewhat less than the Sun-defined set of libraries that are in the JRE. Clearly you're saying, "that's wouldn't be Java", but it's an issue that I think will show up on day 2 after release, my guess being in some Linux distributions (packages like "light-java", "java-min", etc.).

  What seems to be missing from the discussion about open-sourcing Java is that Sun still controls a large part of what the platform specification includes. Is there, or was there ever, a JSR for Swing? I can't seem to find one, and boy, is that a large set of classes. How the heck did that make it into the platform without an open, community-driven discussion behind it? (that said: I like Swing a lot and participate in the SwingLabs projects) It's fine for Sun to say, "you must ship what's in the platform specification", but if the platform specification is not fully, completely, end-to-end open for discussion...well, you can imagine the discussions that will take place on the meaning of the "platform" after the open-sourcing begins.

  But am grateful for the rest of your clarification.

  Regards, Patrick

  Posted by: pdoubleya on August 23, 2006 at 02:23 AM

• Hello David, My irritation was with SWT (specifically the extra work it is causing me), not open source Java which I'm very much looking forward to. And I do understand that additions to the platform outside the java.* and javax.* namespaces are entirely legitimate - SWT is just a third party library that has gained a significant market share (because developers like it, presumably), it is not a fork and the Eclipse Foundation could bundle it with a Java runtime and still call the resulting package "Java", provided that they didn't remove anything (like AWT/Swing).

  But this did get me speculating about how the Eclipse Foundation's powerful distribution channel could be used to put some other compelling new feature(s) in front of Java developers, but this time USING the java.*/javax.* namespace. This couldn't be called Java, at least that's my understanding (you are not allowed to pollute the java.* namespace), but I don't think the market would care so much about that, as long as their existing applications run as expected (and they would if this runtime is derived from Sun's code with nothing removed). Pretty soon developers would be coding using new classes in java.util.* (for example) that ONLY exist on the Eclipse runtime...and we'd have Java developers split between two platforms, the Eclipse platform and the Java platform. I hope Sun has a plan for minimising the risk of it happening. I'd say it is one argument in favour of a strong copyleft licence. Regards, Dave Gilbert.

  Posted by: dgilbert on August 23, 2006 at 04:46 AM

• Patrick, Actually it's the JCP that defines the platform. JCP is technically a separate organization, though I suppose you would say Sun controls the JCP so it doesn't matter. I've not been involved with the JCP so I don't know how much Sun controls or doesn't control what happens there.

  I don't remember how Swing got into the platform, but the JCP did exist at the time. I do remember one bit of public discussion ... under what package name should Swing be integrated with Java? I don't remember the options but javax.swing was only one of several choices that were being debated publicly.

  Your point about whether the JCP controls all changes in the platform spec is interesting. Actually the JCP does not do so. There are a sizeable number of "small" changes that we review and approve as a side-process to the JCP. We have an internal committee, of which I'm part, the CCC, which reviews proposed changes to the API's and other "interfaces" (using the word loosely) to the Java platform. A typical CCC request might be that in order to fix bug# 5693212 they have to change a method definition, change the set of exceptions thrown, add some methods, add some classes or just document existing behavior more carefully. The CCC also reviews all changes required by a JSR committee, but those changes have already gone through so much review that by the time they reach the CCC it's already okay. There are some changes that only go through the CCC. I don't know where the breakdown is between something that goes through a JSR and something that doesn't, except that as I said "small changes" don't have to go to the JCP for review.

  That's the current practice anyway. Our discussions of how to operate as an open source project might make some changes to the process.
  

  Posted by: robogeek on August 23, 2006 at 05:34 AM

• Oh, and CORBA ... sigh. But isn't its presence kind of like Microsoft continuing to include WIN32 in Windows? In the name of preserving backwards compatibility don't old API's continue to have to live, even if they're crufty? I use a Mac (at home) and one of the things bugging the Mac community is that Classic Mode has been shed in the move to the Intel processors. That's irking the Mac community a bit, in that their old games or whatnot isn't working any longer.

  Posted by: robogeek on August 23, 2006 at 05:37 AM

• Hi,
  What about java ME?
  If you have support for Java ME/CDC1.1, Foundation Basic and not Personal Profile, instead adding eSWT.
  (I mean Personal Profile is a optional package)
  Could you call it Java?
  -ove

  Posted by: ovjo122 on August 23, 2006 at 06:33 AM

• ME? I know nothing about how (if) the platform definition rules vary with ME.

  Posted by: robogeek on August 23, 2006 at 07:19 AM

• What a horrible situation.

  This opens the door for a predatory monopoly to "extend" Java with classes that only work on say Windows... given the popularity of said monopoly and the convenience of these "extensions" the reality of Java could become that of a platform that works great on Windows and doesn't do much of anything anywhere else. All it takes is someone to bundle something that makes using the platform specific classes to good to resist.

  I think that Java is open enough now. The poll on Java.net shows that there is a significant group that agrees with me.

  Posted by: swpalmer on August 23, 2006 at 07:42 AM

• Removing things isn't the only way to break existing code. Adding new things that conflict with existing code does the same just as well.
  Just add it in a way that means a change to the bytecode instructions that already exist and you have your breaking implementation.
  People doing that unintentionally is bad enough (and there will be more than enough of those, just wanting to "fix" something that ain't broken but they in their ignorance think it is), but others will do it on purpose.
  And once the language spec and TCK inevitably follow the runtime (the open source zealots whom Sun is surrendering to in this move won't stop at anything less) people can just change the language spec themselves to mean what they want it to and call it Java with noone able to do anything about it.
  I've pretty much decided I'm going to stick to 1.5 (5.0) and tell customers/users that only Sun 1.5/5.0 runtimes will be supported. Anything else and you're on you're own.
  Or maybe I'll just create my own little JDK/JRE for the heck of it and force my users to use that and nothing else, which seems to be what a lot of people are going to do in order to make sure their application will work the way they indend it to.
  

  Posted by: jwenting on August 23, 2006 at 09:21 AM

• David: thanks for the clarification on what is and what is not the responsibility of the JCP. My sense is that the Java team at Sun actually makes more than just a few non-JCP API changes, but will drop the point until we see what happens with the open-source effort.

  jwenting: A given JVM installation could be verified using some hashes (e.g. MD5) downloaded from Sun.com--you'd just need a single utility (or script) which would download the hash-set from Sun, then run it against what was on that machine, comparing file-by-file (rt.jar, binaries, etc.) to verify that you had an "official" release. I can't tell you the exact mechanism to use, but this seems pretty straightforward to do, as long as the "canonical" hashes were available from a resilient server (e.g. java.sun.com).

  Regards, Patrick

  Posted by: pdoubleya on August 24, 2006 at 06:35 AM

• Hey if Derby's going in the SDK, SWT should definately go in the SDK (just kidding!) :)

  Posted by: phlogistic on August 28, 2006 at 07:44 PM

This work is licensed under a Creative Commons License.