Posted by editor
on February 23, 2009 at 8:56 AM PST
New concerns about Swing's status... also:
Weblogs: Ask the JCP ME EC candidates and backward-compatibility hacks
Forum Posts: Seeking GlassFish appclient feedback, Xlets and LWUIT, and seeking autocompleting text field for LWUIT
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.
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 http://wiki.jcptest.info/boards/index.php?b=2 ."
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. "
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] javatv-developers.dev.java.net."
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="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
Archives and Subscriptions: This blog is delivered weekdays as
Today RSS feed . Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the
New concerns about Swing's status