In the late 80s I was a customer of James Gosling: I had UniPress Emacs on my AT&T Unix PC. This was way before Java. So I have a deal of affection and respect for him. I really loved UniPress Emacs.
But a recent interview with him makes me think he lives in a corner of reality fairly removed from mine. He claims the “people the open source movement” don’t provide any “coherent answer” as to why Java should be open sourced.
It can be summarized, or at least exemplified, in a single contraction: HTML.
The implementation of HTML in Java hasn’t changed in a decade and is now so far from acceptable even Java, whose design rationale above anything else is Write Once Read Anywhere, now just provides a kludge to embed a non-Java browser. Yet Java claims to be a web technology. What a load of bull. Swing’s development effort should be realigned around integrating public-contributed enhancements as a priority over new code.
The HTML browser case is a clear example of Java’s management and development over the last decade failing people in a major class of applications. I don’t care if Sun maintains tight control of non-GUI Java; but they have long ago lost any right to respect or trust from the developer community interested in non-server, non-micro-device desktop applications. SWT’s widespread adoption is a symptom of this.
Now, of course, there are a lot of positive signs. There is an open source XHTML browser project called Flying Saucer at javadesktop.org that looks like fitting the bill. That site is such a positive thing for Java desktop developers; it shows that there is so much promise in Java yet. And NetBeans at least has provided a Sun-internal customer that gives some desktop-application-related input into Java.
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)
An Open Sourced Swing would be good propaganda for Java, assuaging programmers who currently ask “well, they haven’t actually open sourced Java yet, have they?” Open sourcing Java will undoubtedly take a long time, so doing it a chunk at a time may be a good strategy. But people with long memories may care to remember how Sun was going to persue ISO standardization of Java, then pulled out in favour of Ecma standarization, then pulled out a set up the JCP: Sun are control freaks and the abysmal state of portions of Java (like the pathetic maintanence of the HTML code) is a symptom of this. Of course, it is not enough to Open Source something: the mechanism for speedy response to bug fixes and releases is crucial too.
I think that had Swing been opened a few years ago it would be even more robust than it is now. I agree that the HTML rendering is below par.
However, to say that it's only Swing that has been neglected is wide of the mark, and there are many areas throughout the entire API where people can spin off an argument equivalent to this blog post. So, it's probably best that the entire platform is accessible under the same OSS license.
I think SwingX is enough. It's a great place to do open source Swing development, and its still kind of official.
I disagree with the "wide adoption of SWT" statement. At least I haven't seen any evidence of that. I use many Java applications at work and at home and none of them use SWT. The applications we develop at work rely on a consistent L&F regardless of the platform. I'm under the impression you can't get that with SWT. Am I wrong?
Perhaps you missed the news, but we have been accepting contributions to Swing for quite some time at http://jdk.dev.java.net . In fact we've taken a number of contributions from a handful of folks, leouser has contributed > 100 fixes! If you deeply care about seeing Swing's HTML support improved, send us the diffs!
I don't intend to start a flame war here, in that I suspect some folks will say Sun hasn't really open sourced Java yet, which is what this blog is calling for. None-the-less if you really care about seeing Swing improved, and specifically Swing's HTML component, we have provided a more direct means for you do that now. Send us the diffs, we are looking at them and responding.
-Scott
"It can be summarized, or at least exemplified, in a single contraction: HTML"
HTML is an abbreviation. I guess we're still looking for a coherent argument.
Oh, and if you want to fix it, why didn't you contribute to Mustang?
There is a lot of active, non-Sun development for Swing, in both commercial and open-source spaces. That's been going on for some time. Sun has sponsored the SwingLabs project which includes new components, a better SwingWorker, desktop integration, among other things.
I'm one of the developers for Flying Saucer, and I can tell you that part of the issue with a XHTML/CSS renderer is just that it's a hard problem. There's a lot of code involved, a complicated CSS spec to implement, and lots of corner cases. I don't fault Sun for not taking that on, given the many directions in Java development that they pursue and support.
As far as open-sourcing Swing, your point begs the question of how many open-source developer there are that can contribute meaningfully. I don't mean to insult anybody by that, but rather want to point out that the low-hanging fruit in Swing development were picked long ago, and most of the problems that remain, or areas where one wants improvement, are just difficult design and programming problems. Look at the mail archives for the SwingLabs SwingX project--there are basically few simple answers available. Also, note that SwingLabs is all released under OSI-approved open-source licenses. The question is whether there really are a lot of developers just waiting to contribute, who really can push the thing forward, but who are held off by licensing.
By the way, there are commercial HTML components for Java, in pure Java, such as WebRenderer. These are high-quality, up to standard, and cover all the features you want. We can't expect Sun to do everything.
Cheers
Patrick
I thought the advantage of Swing was that it had real widgets and an API across platforms. From this article it would seem that what Java is merely just a poor host container for HTML. So going forward, should it support W3C HTML, Microsoft HTML, FireFox HTML or KHTML? or a mix of these? Which scripting engines? Which incompatibilities do we need to introduce to keep it on par with browsers? Being an antiquated "codehead" I'm used to building apps with solid APIs not DHTML hacks so you'll have to bear with me.
Why can't Sun activly develop swing anymore? Low hanging fruit or not they seem to have all but forgotton about it. SwingLabs? How many Sun employees actually work there?
Near as I can tell there is one employee who still works on JMF, but people still want the functionality.
Yes, we do remember about the ISO, ECMA and all those major screwups. ;)
Why can't Sun activly develop swing anymore?
Huh?
Have you seen the number of desktop related features going into mustang? Take a look at http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/index.html for a list of the major desktop related features.
Dolphin is looking like it'll be even bigger and better. There are two very large Swing related JSRs ramping up now: JSR 295 and JSR 296.
-Scott
Scott Violet: "None-the-less if you really care about seeing Swing improved, and specifically Swing's HTML component, we have provided a more direct means for you do that now. Send us the diffs, we are looking at them and responding."
Scott, respect you tremendously, but in this instance, I think the reply is a tad simplistic. As mentioned earlier, a lot of the low hanging problems have been remedied. Improving the HTML rendering to be compliant with the latest HTML+CSS specs will require more than a few diffs from little ol' me. It's my (perhaps naive) view that the system currently in place for contributions encourages invididuals to make patches, rather than promoting/supporting team efforts for difficult and time comsuming tasks.
One could therefore say that Flying Saucer is your "diff". Another team has done the hardwork of making a fabulous OSS html/css renderer. Can Sun not exploit that resource?
On a positive note, I think Swing is great and Mustang's improvements are looking great. I hear you've got a fabulous new recruit to help with JTable and therefore things are looking even better :)
First, I'm not an employee of Sun.
Second, I've been doing nothing but Java Swing applications for the last 6 years.
With that being said I can honestly say this article is WAY off topic. Let me count a few important items.
1. The source code for Swing and AWT is available for you to read and tweak. Name me another vendor who gives you the full source for their widget API? Anyone got a clue what all of the API calls are behind the .Net curtain? ;-)
2. The Swing team has put excellant articles up on their web site. They blog on important topics. They are available to help.
3. The SwingFX web site is available and you can download the code or contribute.
4. java.net has LOTS of Open Source projects that extend, enhance and build on the Java Swing components. There is some really cool stuff out there.
5. Sun's new CEO at Java One said they WERE going to Open Source Java NOT just Swing so this article really seems like it doesn't have a clue what is really going on in the Java world.
Finally let me just say that this Java One was by far the BEST Java One ever for showing the future of Swing and desktop applications written in Java.
Go look at all of the new JSR 'Open' projects where the API will be rolled into a future release of the JDK.
Does the author know ANYONE else in the software world doing that and NOT being considered an 'Open Source' vendor?
What is interesting about the responses is how hard they try to avoid the issue. Open sourcing would not be good because I use the word "contraction"? Open sourcing would not be good because Sun has a bug reporting system in place? Open sourcing would not be good because if the HTML is usable people will use horrible DHTML instead of WORA Java? Open sourcing would not be good because competitors like Microsoft are closed source (err, what about SWT and X windows?) Open Sourcing would not be good because we have a couple of exciting JSRs? People should contribute fixes to the HTML code when there is now Flying Saucer hanging around? People who want HTML improvement should contribute to Flying Saucer when they don't know whether or how it might be grafted into the official HTML support?
The silliest of these is the suggestion that Swing doesn't need to be open sourced because Sun says it will open source all Java real soon now. We have had Sun people commenting how hard it is to even get the Java license for Linux together.
So my suggestion for Swing is as a first chunk: it is meant as an encouragement not a chastisement! If Sun is apprehensive about the details and desirability of open sourcing, just do it for one chunk first, then evaluate how it has gone. UIs clearly have special characteristics wrt development & market position; indeed, many devices don't support graphics. And Sun has partitioned Swing development in a way that would allow more freedom.
Now, I do submit bug reports, see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4755500
And I do submit open source code to javadesktop.org, see
https://flamingo.dev.java.net/
And my company happily releases Swing desktop applications, see http://www.topologi.com
But look at item number 7 on the Sun bug database list of 25 most popular requests for enhancement: html4.x suport in a JEditorPane. The responses: "We will investigate improving support in this area for merlin." and "This is something we are strongly considering for dolphin." The originating request was 1999, for Java 1.2.n. In March 2006 is a sad little note "no news?" (And, by the way, I would say that the need for proper standard HTML4/XHTML/CSS support
in Java is independent of whether it is actually directly editable in a JEditorPane. Reading the comments, this is clear. Sun executives might look at all the free development effort that goes into Mozilla and wonder why they have so successfully prevented this with HTML in Java. Perhaps there was some strategic decision to avoid competing with Mozilla, in order to have at least one creditable alternative to IE: that would be a much better reason for the state of things than slackness, which is very hard to believe.)
This is not the first time I have raised this issue. But I don't see that much has changed in the 25 months since that post.
Let's look at an example. Bug 4233012 basically prevents most well-conforming HTML 4 documents from being parsed correctly. It is a bug because an exception is generated about an encoding declaration in markup *after* the document is already in Java strings as Unicode text; a completely useless exception is generated. The encoding declaration may be used by (e.g. some homemade) byte->string file opening methods, but won't be stripped out. The presence of the exception code is a bug, pure and simple. It isn't that Java's HTML doesn't implement some funny extras; it actively rejects even innocuous documents that are written properly. But this was marked as "not a bug" and closed. Who would raise this again, given the high chance the issue would be marked as already dealt with?
Rick, in many ways, Sun is trailing years behind everyone else, and stands to become entirely irrelevant for the future of the Java platform, other than as a potential SCO-like legal obstacle.
Sun could wait out opening their code base until Java 1.6 is released, and try to capture some momentum away from FSF's gcj/GNU Classpath & ASF's Harmony. That may or may not work, and a piecemeal tactic could work in Sun's favour there.
They could also wait it out until 1.7, and lose more ground to FSF & ASF, and .NET, of course, thanks to Vista bundling WinFX/.NET 2.0. The history of IE vs. Netscape, WMP vs Real, etc. shows that the bundled proprietary solution wins on Windows. Or Sun could wait until 1.8, assuming Sun still exists in its current form in 2010, and do something of comparable relevancy to the opening of JINI ;)
Afaict, Rich Green has still not started talking with the Java community, despite his announcement at JavaOne, and that's a surefire way to failure. Sun is incapable of shouldering open source Java alone, as it does not have neither a visionary management in the Java division, nor does it have the sort of people who can rally the community behind a common goal. Most of all, Sun does not have a focus on quality and transparency, as one can see from the pretty poor, intransparent Sun-led J2SE JSR in the JCP, like the Swing API specification in particular.
Dumping Sun's bitrotting code over the fence, without a focus on quality, is going to work as well for Sun as opening the Netscape browser did for Netscape. Netscape's unmaintainable code eventually was largely thrown away to make way for Mozilla/FireFox, and it didn't prevent Netscape from tanking.
The future of Java lies outside Sun. The sooner Sun's management gets that, the larger a role Sun could play in shaping it.
Well, I don't know about Java management not being visionary (Java still seems pretty visionary to me), but I wonder how much James Gosling's past personal feelings (Richard Stallman says he developed the GPL as a result of what seems to be a fairly bitter falling out the two had) tempers his enthusiasm for open source, or at least influences his or his collegues' inclination to dismiss it. Java has spawned an incredible number of open source projects, and almost none of that technology has ever found its way back into Java; the chances for consolidation are wasted.
I think the contribution of Harmony to be an open source Swing implementation also changest things. It opens up the possibility that someone might want to use Sun Java core but with the GNU Swing implementation, or vice versa! That kind of modularity would be good for users.
Andy, thanks for the kind words. I wanted to respond to a couple of your points.
Improving the HTML rendering to be compliant with the latest HTML+CSS specs will require more than a few diffs from little ol' me. It's my (perhaps naive) view that the system currently in place for contributions encourages invididuals to make patches, rather than promoting/supporting team efforts for difficult and time comsuming tasks.
The scope of the diffs we've been getting via jdk.dev.java.net are all over the map. Most are the smallish ones, but a couple of folks have contributed gargantuan patches. A patch for adding generification to many Swing classes was recently submitted - talk about big! So, it's really up to you as to what you would like to submit. If you do want to do a large change, I would suggest contacting us before hand, that way we can all work together to make it happen successfully.
So, if you did want to improve Swing's HTML support, and move it toward html 4.x we would not out right say no, it's too big. But if you are serious about this, or others are, we can work toward making such a project a success. Start up a discussion on this over at jdk.dev.java.net and we can take it from there.
I should also mention our internal process. For anyone watching our weekly source drops you'll notice we do not putback half baked fixes or features. Instead each individual (or group of individuals if the scope is big enough) will work in their own workspace until the fix or feature is complete. Only once they have the feature working, tested, and reviewed does the change get committed. In many ways this is similiar to getting a gargantuan set of diffs at a certain point.
One could therefore say that Flying Saucer is your "diff". Another team has done the hardwork of making a fabulous OSS html/css renderer. Can Sun not exploit that resource?
Josh has taken a much different approach. Flying Saucer does not use Swing's text package or try to fix what is there. It's a completely new architecture and approach. I'm not convinced this is warranted, but I have not studied flying saucer in any detail. If the community believes flying saucer is the way to go, then we should have that discussion. The text team would be happy to have such a discussion over on the jdk.dev.java.net forums. One caveat though, if we do decide flying saucer is the way to go, it would require a JSR. It's beyond the point to which it could be included without one.
Again, thanks for the praise on mustang. Glad to hear there is some happyness:)
-Scott
Rick,
I'm confused about your main argument. It seems as though you have argued that Swing's HTML support is not good, therefore open source Java (or perhaps just Swing) and suddenly Swing's HTML support will be better. Is that your main point?
If so, what doesn't work about jdk.dev.java.net for getting fixes and enhancements back into Swing? Why would you expect that if we open sourced Java (or just Swing) that this would change?
-Scott
Scott, the "suddenly" is your word. What does it mean?
I want open source because when I find an error and a fix, I need to be able to distribute a fix for my customers on the same day. This may mean a temporary customized JRE.
I want open source because when I find an error and a fix, but it does not fit in with your priorities or when (as in the case of the HTML encoding bug) it is a design error not a coding error and therefore gets treated as a feature, I want to be able to disagree with you and maintain a private fork that acts the way I need it to act.
I need open source because I may want to change the implementation of a built-in package, for example to provide a facade on swing.text.html to implement it on top of Flying Saucer.
Looking at the JSRs for Dolphin, we've got several NIH-influenced attempts from Sun to emulate OSGi with superpackages, JSR 277 (the super-secret one nobody apparently knows anything about), and of course, the rather pointless invokedynamic JSR, which doesn't really help anybody implementing a dynamic language with different semantics from Java on top of a JVM.
That's what I mean with a lack of a visionary management. Sun's Java management is stuck on the premise that the world will, for some reason, rewrite everything in Java, if it only is marketed well enough, for example as 'better than open source', or similar nonsense. From my discussions with Sun's managers, I believe that Sun's management is stuck thinking how to leverage Java against Sun's competitors, rather then thinking how to improve the platform for everyone's benefit.
As the past few years have shown, a lot of people are fed up waiting for Sun to finally get their act together, and start acting like open source leaders in the Java space. The Java platform needs modularity to stop the necessity for inclusion of unmaintained junk like the 'standard' HTML widget into the J2SE library, it needs to be more accessible to people who don't use Java, and it needs to allow developers to be productive building on the wealth of open source outside Java *easily*. It needs to be ubiquitous.
Those things are what Kaffe, gcj, GNU Classpath & Apache Harmony address. Sun, meanwhile, seems to be focusing on producing more bogus binary code licenses.
I want open source because when I find an error and a fix, I need to be able to distribute a fix for my customers on the same day. This may mean a temporary customized JRE.
That is certainly an understandable need. I believe we offer the JRL (java research license) and the JDL (java distribution license). Initially we were very restrictive as to what you could do with the source bits provided on jdk.dev.java.net, but I believe that has changed. Have you looked at the JDL? I'm not suggesting it meets your needs, I don't know the entire scope of the JDL but it might be what you are after.
But I'm still interested in your main point that Swing will get html 4.0 support if we open source Java (or Swing). To date we have received a number of fixes, the majority from one guy:) So I remain skeptical that open sourcing it all will suddenly open the flood gates. But who knows, I could be pleasantly surprised and find that there is a set of folks that do have the time and can contribute quality patches.
-Scott
"Sun executives might look at all the free development effort that goes into Mozilla and wonder why they have so successfully prevented this with HTML in Java. Perhaps there was some strategic decision to avoid competing with Mozilla, in order to have at least one creditable alternative to IE..."
This comment really confuses me. Mozilla and IE are BROWSERS. Rendering the latest and greatest HTML is what they do! It could be that Sun executives realize that the scope of Java far exceeds that of a browser and that HTML support is one of many priorities which also include network IO, database access, 2D rendering etc.
Sun's stewardship of Java has kept it reliable and stable over the years.
Well, my argument is that Swing *would have* gotten HTML 4 support if it had been open sourced. When researching different HTML browser components in Java two years ago, I came across one that was exactly the Sun code updated. I think they withdrew it because of licensing. I hope whoever it was decides to contribute the code back to the JDK as you suggest.
Scott, you again talk of the "latest and greatest". But that bug I pointed out, which goes back from the beginning, stops even the most basic well written HTML 3.2 that uses HTTP equiv in meta tags. That is a 10 year old spec, not latest and greatest. Get the latest and greatest out of your mind. Get the latest and greatest out of your mind.
Patrick Wright wrote: ...By the way, there are commercial HTML components for Java, in pure Java, such as WebRenderer."
Patrick, please let me to put this straight for the record: WebRenderer is NOT pure Java, they use a native Mozilla Gecko engine for their HTML rendering. Just look into their webrenderer-win.jar, you'll see a webrenderer.dll. That's the native Win32 Gecko Engine. They basically only provide a Java wrapper to that.
I really don't think this can count as a solution for the HTML rendering and editing issue in Java.
"The implementation of HTML in Java hasn't changed in a decade... Yet Java claims to be a web technology. What a load of bull."
"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."
Aren't you being too harsh? Didn't they just start a new rich internet app project?
Alas...."codeheads" are evil..."tagmonkeys" are the only real application developers...
Rick: This is the part that scares me about open sourcing Java.
"I want open source because when I find an error and a fix, I need to be able to distribute a fix for my customers on the same day. This may mean a temporary customized JRE."
The following week, I'm at "your" clients site trying to implement something, but they have your hacked-up JRE installed and my changes don't work correctly. Now what? Do I correct your hacked-up JRE or go to Sun? Where does it end?
I say no thanks to Harmony. If you want to contribute, then join the existing channels for doing so. If you need a quick JRE fix, then do as Scott as instructed. The options for you are already in place.
As for the HTML support in Swing. We write Java code, so the HTML support that is already there is sufficient to enhance the display of our labels and text components. Anything beyond what is already there is a "nice to have", IMO. Again, you have the option to contribute to make it happen if you are serious about making it better.
Erik: don't be alarmed! The debugged JRE would be distributed privately with the application and not replace the standard installation, so other applications can continue to use the buggy JRE in peace :-) (And I should point out that I am not talking here about changes to abstract functionality or API but fixes to how that functionality is implemented, in case that red herring thrusts itself into view.)
Chris: if you read my stuff and see "codeheads are evil" you need a holiday. But I apologize if I wrote something that gives this impression, but honestly I don't see it: the most I would say is "Codeheads miss a great opportunity and hinder a useful, practical, efficient technique which utilizes Swing's reflection and the beans conventions to another level".
Anonymous: yes I am being harsh. Some people involved in Swing development are really cool with (generic) XULs; Joshua Mancinni wrote a good article on SwiXML for example. With (generic) XULs you have a great technique that has proved itself to Mozilla, Microsoft, and a myriad of other developers, including proud-to-be-a-Swing-developer like myself. We see it everywhere except one place: JDK Swing. (I have written elsewhere of how adopting SwiXML reduced our editor's interface by over 600K of code.) Why hasn't it been in Swing for three or four years?
"...Joshua Mancinni wrote a good article on SwiXML for example."
I know it's a little hard to remember, but it's Joshua Marinacci instead of Mancinni. ;)
Apologies to Joshua about the typo there.
Also a heads up that Chris Adamson has a thread on this issue at his blog too.
I thought I'd look through some of the reported bugs in Swing's HTML, as a prelude to taking up Scott's challenge to contribute to the JDK forum.
First you need a login to the JDK. I already had that for javadesktop.org, and I've had several Sun site logins in the past. So I logged in (and updated my password.) Then you need to fill in a form to say you want to be a Researcher. OK. Then you need to wait for Sun to approve you. Err, sometime soon.
After the approval comes, you then sign and fax a form in. Then you fill in an online form, it seems. I'm not there yet.
But even before emerging into the respendence of contributorhood, I decided to have a look at the HTML bugs and their resolution, to get better informed.
Bug 6245596 was interesting. Unknown entities get transcribed to the output with no trailing semi-colon. Doesn't seem a big deal to me, as the error behaviour here is not specified in HTML or SGML. But the discussion of the error from the Sun engineer was bizarre, claiming that HTML 3.2 did not have character entities.
So I tried to fill out the form, being a helpful person by nature, to point out the URL of the section of the HTML spec.
But then the bug system claimed I was not logged in, that I would need a login to the Sun Developer Network. So much for Sun's unified password system.
The message I am trying not learn here is that Sun will ignore your bug reports for as long as possible, give a bogus answer to them, and prevent you from registering any further comments.
Apparantly Sun are going to do it. See here
The open source model offers an entirely new way for developers and increasingly knowledgeable, interactive users to collaborate and build upon the best of the commons. The result: open source is reaping tremendous leaps in innovation, and standards-based, interoperable solutions
Choudhury