Skip to main content

Haven't We Been Here Before

Posted by editor on February 23, 2009 at 8:56 AM PST

New concerns about Swing's status

Last fall, one of the big stories in the Java community was the status and future of Swing, after it was revealed that Sun was no longer funding a developer on the SwingX project, a move that Kirill Grouchnikov took to be a de facto freezing of Swing. In Sun setting down on the core Swing, he wrote:

All i know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX

So, about JSR 296 specifically... in July, the question came up as to whether it was in a "coma", with the departure of its founder. But in August, Alexander Potochkin took over as project lead and updated the project status in his blog.

But have things gone dark again? Anthony Goubard complains that work on the Swing Application Framework seems to have seized up again. In the Javalobby post The Swing Application Framework Still in Coma, he writes, "As already said a few months ago, there is no activity on JSR 296 (SAF) and nothing much has changed since then. Note that this JSR is a candidate for inclusion for Java 7. In the meantime Alexander Potochkin has taken the Spec lead and worked a bit on it a few months ago but for a least the last 3 months it's again quiet from Sun."

As recently as last week, we had unofficial Java 7 content-tracker Alex Miller predicting that JSR 296 would be in Java 7, following Mark Reinhold's inclusion of it in his Devoxx 2008 presentation on Java 7 features. So if the Swing App Framework really is in trouble, that's going to be an unpleasant surprise to a number of people.

Also in Java Today, A. Sundararajan has posted a slide set introducing JavaFX for Java and JavaScript programmers. "I missed attending and speaking at Sun Tech Days at Hyderabad due to a personal reason. In fact, I prepared slides for a talk titled "JavaFX for Java, JavaScript programmers". This is much like my earlier language comparison blog entries such as Java, JavaScript and Jython, Java, Groovy and JRuby etc. The idea is to learn a language by language comparison - and not to conclude "better"/"worse" language and so on. [...] Although I could not attend Sun Tech Days, I am posting the slides here : slides in a .pdf file"

In A tale of three code generators, Andrew Haley digs into the bytecode generated by Zero/Shark, GCJ, and Hotspot. "Shark is a port of OpenJDK that uses LLVM to do JIT code generation. While Shark is pretty fast when compared with OpenJDK's C++ interpreter, it's still quite a lot slower than gcj. gcj is a fairly straightforward bytecode->native compiler and doesn't use many of the Java-specific optimizations in HotSpot, so I was of the opinion that Shark and gcj ought to be similar in speed. So, I wanted to find out why Shark was slower than gcj."

There's an interesting bit of JCP Elections outreach being spotlighted in today's Weblogs. In
JCP EC candidates ready for questions in election forum, Sean Sheedy writes, "four candidates are competing in a special election for Intel's ME EC seat, vacated in January. For the first time, a forum has been created to permit questions from the community and encourage debate between candidates. Please make this election interesting and help surface the best in the candidates by visiting"

Volker Simonis shows off some heroic backward-compatibility in "We need a 'dirty hack' (but a brilliant one)...". "Usually it's not big fun to be "supporter of the week" but recently, when I was on duty, I got this somehow unusual request on our support queue. If you're interested in Bytecode Instrumentation and Rewriting, Classloaders and Instrumentation Agents read on to hear the full story..."

In today's Forums, tjquinn wants opinions from GlassFish users in
If you deploy app clients we need your feedback on some choices in v3!. "We want to improve several things with app clients, in particular the launching performance when you use the appclient script. (This topic does NOT apply to the Java Web Start support for app clients in GlassFish.) We have some choices to make and we want your feedback. The options have advantages and disadvantages. Please read the summary below and reply to this entry to let us know what you think. If you see other pros and cons or think of other options we should consider please mention them. "

tamir gives some idea where LWUIT is going, in the followup
Re: Any example to make LWUIT work with Xlet? "Our road map, that will include also the Xlet support, will be implemented soon, but i don't want to commit for how close it will be released. So please stay tune for our next SDK drop and our coming soon announcements. I encourage you to register to our email alias: announce [at]"

Finally, rosstheboss wants to use LWUIT for an
Autocomplete Textfield. "I'm working on creating a auto completing text field, a bit like the example I once saw on the blog. I'd like to have a suggestions list (scrollable) appear underneath the text field appearing to be part of the text field, and overlaying any other components on the field. An example of how this best works is the search within firefox. Any suggestions on an approach to this would be great, I'm going to handle data using a model and filterproxy."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

New concerns about Swing's status


I have given up on JSR-296 all together. I started a very large project built around the API, hoping that we would incrementally fix the broken pieces as changes came in. But, it's been a year and nothing. We did find the API very lacking, but hoped this was due to its youth. We have now decided to remove the sun dependencies and just continue with our own framework that came out of it. Oh well. I dig swing and I do not wish to jump onboard the JavaFX wagon (yet, or perhaps ever). It is just not worth it. Plus, the risks involved in such 'revolutionary' (not necessarily a good thing) change are just too dangerous for most companies. That's just my current situation, Briggs.

It's dead, Sun just needs to own up to it. Let's not forget JSR-296 relies on JSR-295 which has already been excluded from Java7.

Alex has been absent from the public AppFramework lists ever since. And Karsten has confirmed the same for the EG mailing lists. And if Karsten votes "no" for the inclusion of JSR 296, it is a sure sign for me that it must not be included in the official JDK distribution.