Related link: http://www.infoworld.com/article/04/03/05/HNibmsunmeet_1.html
Java already has chunks from IBM-sponsored Open Source projects:
the XML libraries from
Apache
and the Taligent-derived internationalization technologies developed by Mark Davis' ICU4J team.
IBM is talking to Sun about some kind of further Open Sourcing arrangement for Java.
Java is openish: it has a community process to guide the development of new libraries, its source code is readily available, it puts out betas for advance feedback, and it has had a bug tracking forum with voting to allow the least popular bugs to be tracked (and, I suppose, to get addressed earlier: nice if everyone really has the same bugs.)
Looks good? but there is also a dynamic at play which keeps some parts of Java in the doldrums, and I don't see that shifting Java over to some IBM/Sun-sponsored consortium would necessarily make much difference.
Open Sourcing can only deliver the benefits of 10,000 eyes when feedback and enhancements can be merged back into the code base fast. Any organization dealing with code fixing must prioritize their fixes according to their own lights and capacity. As Joel on Spolksy creepily
"http://www.joelonsoftware.com/articles/fog0000000014.html"
>puts it Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.
So Open Sourcing is effective when it allows the people who have the value requirement (the users of the code) to get the code fixed: the owners of the code simply may not have the value requirement, especially for a loss-leader like Java. Shifting all the J2SE holus-bolus from one big organization to another might help broaden the priorities for fixes and enhancements, but that simply is not the game we should be playing. Anyone who has waited for known bug fixes to be folded back into Apache Xerces, say, will sympathize.
It would be better for Sun to look at the parts of Java that do not lead to server-sales or profit, and to farm them off into smaller, separate, focussed, Open Source efforts whose can concentrate on maintaining them. The name of this game is No Resource Contention: the community interested in one library should be able to concentrate on it.
One library that leaps to mind in this is javax.swing.text.html. Arthur van Hoff's great parser class has not changed much since it was created, around 1994: it implements a now-sucky HTML 2 which cannot handle XHTML ( /> empty elements, ઼ hex character references, and so on), let alone HTML 4 or W3C DOMs. Its nice SGML-compliant features have never been developed further, and it has a show-stopping flaw for the modern Web: you are bound to get an encoding exception if you try to feed it with an HTML document as a String in the harmless/typical case where the markup has a meta tag that specifies the MIME Content-Type and encoding.
Of course, this all reflects Sun's earlier priorities, where Java applets run inside browsers; but how I envy Windows programmers, who get to use Internet Explorer as a component when they need it.(In fairness, Sun has not being doing nothing for HTML: the latest 1.4.2_04 release this week has a fix relating to frames, for example. And maybe they will be serious about their recent Java Desktop brand.)
Democracies prevent mass interest from swamping regional requirements by having independent secondary or tertiary tiers (e.g., states or local councils). It is fine to have a senate deciding on JCP, and mass voting deciding on bug priorities, but Java needs an organizational process to farm value from autonomous efforts so that the users are the developers.
Even if Sun prefers to retain control over a stragic asset like Java, it should take a hard look at the components of Java that are related to platform-breadth and market-reach rather than to profitability, and slough these off to small, reactive Open Source efforts. javax.swing.text.html would be a good component to start the experiment with.
Categories
Web
Comments (7)
Read More Entries by Rick Jelliffe.
Become an O'Reilly Member
Visit the Digital Media Forums
Subscribe to the Digital Media Blog Feed
Subscribe to the Digital Media Newsletter
Open source will enable Java to explode
Currently, Java development is hampered because most commercial software entities - large companies like Micrsoft and IBM, probably keep majority of their engineers away from JCP. Once it is open sourced, you can hope to see a lot more people contributing to this language and jump start it further. That would also put an end to committee-based-development leading to unnecessary complexities in J2EE etc.
Veekay
Linux and Java
Change is good...
I see 3 major pieces to the Java puzzle: virtual machine (VM), development tools (javac, etc...), and the Java APIs.
IMHO, Sun should seek ISO/ECMA standardization of it VM, language specification, core APIs, and some interesting extensions such as Swing.
By doing this they could open source the development of the APIs and allow third parties and open source projects to implement alternative VMs.
I like the JCP, they shouldn't go away... but instead create a vendor neutral organization where Sun is just another member. Let the industry have final say... so Sun is not able to veto good ideas or squish better technologies (ie. log4j).
Sun wouldn't really be hurt in the long run... they still own the Java trademark. The implementation is now just determined by the community with Sun being just another voice.
Also by open sourcing Java as a whole, Java could be installed by default and used more heavily by open source projects that shy away from it now because of the proprietary license.
entire J2SDK is non-profitable...
I think it depends on how the Open Sourcing program is arranged. One way might be for all the Swing classes to be moved into a separate jar file, which was version-upped independently to the JRE. The JRE releases would just contain the most recent version that Sun's QA had approved. Sun wouldn't lose control or the JRE contents. (Perhaps people could then have their own mixed distributions: SUNs's JRE and rt.jar, the open source "html.jar" and IBM's "i18n.jar"!)
Another way would be to relax the current licenses further to allow versions of selected components (e.g. HTML) to be farmed off for community maintenance at Java.net (similar to the way OpenJade looks after James Clark's SP and Jade programs at SourveForge). ICU4J is an interesting model in this regard: they pioneer state-of-the-art code (that people can use) but then pass it on to Sun for incorporation into future JREs. These are more controlled options than just letting anyone fork and publish the code, though that is of course another option.
But saying "all Swing" goes further than my blog's point: which was that components need to be unified and small enough that small teams which don't dance to multiple masters' tunes can quickly maintain the code. For the HTML library, for example, I don't see that there needs to be DOM support or scriptability: it would be enough that it support the HTML 4 and recent CSS specifications, doesn't barf at XHTML, and handles encodings correctly (and has transparent button backrounds in forms, etc). There is already code around to do all these things. The current APIs should be preserved, as part of the deal, just implemented better. The aim is not "new Swing" (there is already SWT) but "thriving Swing".
entire J2SDK is non-profitable...
Which APIs are core? I mean this less as a question for me to ask you, but as a question for Sun to ask itself.
Java on a Diet
Perhaps Sun can put Java on a diet, and leave some things up to third party--commercial or open-source--developers.
I'm often critical of Sun because they seem to want to throw so much into Java and call it a "standard." But Sun's got a short attention span, so older components sometimes lag while Sun focuses on the Next Big Thing. Witness the HTML components already mentioned, and Java 3D. A sometimes a Sun API replaces superior third party APIs produced by dedicated teams. Witness log4j.
Sure, there's nothing stopping you from using a third party library (several HTML libs are already available), or continue using, for instance, log4j over java.util.logging. But if your colleagues are anything like my colleagues, you'll hear cries of, "But, that's not the standard!" Look to Microsoft for an analogy; many of their products and services succeed not because they are better than those offered by third parties, but because they are bundled.
The Java API is growing bigger with each release, surely at a faster rate than Sun's engineering staff. That by necessity means that certain APIs must fall into maintenance mode, which could mean neglect.
Sun should look at which APIs it is not serious about supporting, and divest them. Sun could donate the source code which could form the basis of an open source project. Having multiple open source modules would be even better than open sourcing Java itself because you could, for instance, update the HTML module without waiting for a new release of the JDK.
Lots of Good Candidates
Certainly the HTML component is a good candidate. There are also lots of APIs just withering away like Java 3D and Infobus - I looked for Infobus a week or so ago on Sun's site and could not even find a download link!
The areas of JavaBeans and Java Media seem to have almost completely stagnated. Client-side Java is now in a catch-22 - Sun won't invest because there's little commercial interest but there's little interest partly because the interesting libraries are never updated! Open source would be a very good option as client-side Java is very much alive in the OS community - you only have to look at the number of OS Swing applications to see that.
Ian.
entire J2SDK is non-profitable...
The ONLY parts of the Java platform that generate serversales for Sun is the J2EE API.
Just letting everything that's not profitable go would tear the heart out of the platform by killing off the core APIs.