In an xml.com blog, Rick Jelliffe argues that the sorry state of desktop Java should prompt Sun to open-source Swing
The poster child for his argument is the utterly inert HTML support in Swing, which is maybe sufficient to render JavaHelp content, or some simple web pages from 1998. It’s certainly not suited to handle arbitrary content on today’s web. But he points out the Flying Saucer project on java.net as an example of a case where the community is picking up where Sun has dropped the ball, and concludes that could be a new model for developing the desktop API’s:
So perhaps Sun could consider this: just open source the Swing tree for now. That is a nice doable chunk, and much work on new Swing development, such as SwingX, is being done in public anyway. Let it evolve independently of the rest of Java. Releases of Java can snapshot Swing. Sun has already lost control of the GUI, because of SWT, and the anti-XML partisans involved in Swing development seem determined to allow MicroSoft and IBM to leapfrog Swing as far as ease of generation of user interfaces (why wasn’t SwiXML grabbed and made part of Swing as soon as the idea was released? — a mystery that is an ongoing fumble by codeheads who don’t get declarative specification using XML)
I’d temper Rick’s enthusiasm somewhat by noting that Flying Saucer’s project owner (and my co-author on Swing Hacks) never intended it to be a general-purpose, real-world web content renderer, so it only goes so far in replacing Swing’s HTML support.
There are similar projects to pick up abandoned Java desktop technologies, such as FMJ’s attempt to provide modern codecs to the flat-lined Java Media Framework (JMF). But there are limits to what can be accomplished — FMJ is working on tying into existing frameworks like jffmpeg and QuickTime for Java, and it’s not clear whether the project would have the skills to implement codecs in pure java or the legal standing to work with royalty-encumbered codecs.
So, could an open-source project pick up the ball with Swing, fix the bugs, and add long-requested features like declarative markup or freeze-dried GUI’s? Could its membership handle the tedious pixel pushing of the striving-to-be-native look-and-feels, or achieve focus and consensus on user interface issues? It’s an interesting idea, but even if Sun agreed to open-source Swing, would it work?
Given continued buzz around open sourcing Java and some renewed vigor and interest in Swing at JavaOne, it wouldn't surprise me.
Jonathan Schwartz will approve open sourcing more Java... When Rich Green was last with Sun, I vaguely recall him saying that he could see Sun open sourcing some of the desktop Java first before considering enterprise Java.
I could see Swing, Java 2D, Java 3D, JMF, and other desktop/client Java API being open sourced and benefiting. How much more is the question...
Lastly, I believe Jini API is open source, already. There's even speculation that Jini may be going into Apache.org as a project.
I don't see open sourcing swing will help, nobody will develop for it. For most it all has to be open source before they will even look at it, just look at the fud which flys when you just want to write an OSS app!
I would like to point out to Steve that Java 3d has been open source at least for the last two years and not a lot has happened.
Jmf has been under MPL License for a while, and many of the desktop APIs have all been added using OSS licences. But yet there has been no pouring in of developers, and I don't see it happening.
From what I have seen the OSS community is very good at making cool stuff, but not the long boreing slogs which turn products into the reliably tools we want.
kangcool: Java3D is not open source. Sun rather blatantly lied at JavaOne a few years ago about opening it up, and didn't actually do much other than to publish a few examples for using Java3D under a bogus license. The rest, i.e. the actual Java3D implementation, is as proprietary as Sun's Java implementation. Sun earned all the positive PR, but did no actual work.
JMF has certainly not ever been released under the MPL by Sun.
Chris, reimplementing already working native multimedia codecs in "pure" Java does not sound very useful.
Sun opening up Swing could indeed be useful, assuming there is something well-written and documented in Suns implementation that's worth recycling in other projects like GNU Classpath and Apache Harmony.
Dalibor Topic writes:
Chris, reimplementing already working native multimedia codecs in "pure" Java does not sound very useful.
It's potentially quite useful if you're on a platform that the native codec hasn't already been ported to. In my experience, 90% of the people who say "native" mean "Windows", so this is a potentially very big deal to Mac and Linux users. Plus, there's always the concept that future platforms could pick up a massive amount of software by just supporting Java, so porting codecs to Java is a sort of future-proofing.
Ew Swing. I suppose that given a load of refactoring the Java GUI APIs could reach a decent state. But given the same effort Eclipse RPC could be given the few missing pieces to completely replace the whole thing.
Chris: Sure, but free software C/C++ codecs are at least as portable as Java codecs, you recompile the libs, and go. Rewriting such a project in Java for the sake of some marketing idea of purity, only means being stuck maintaining something noone really needs, neither the upstream projects nor users.
The marginal effort of recompiling some well-written C/C++ code for a new platform, fixing a bunch of compiler warnings, and debugging whatever issues crop up is minimal compared to the effort to port a JVM, and certify it.
The other wrinkle in all this is that the desire to be 100% Windows LAF compatible turns out to be a fool's errand anyway, because the new Office products are due to have an entirely new style of GUI anyway. WIMP is dead.
Check out how GWT (Google Web Toolkit) has a real nice embedded browser. It'd be great to have in Swing!
-- Andre