Here are some Swing links that you might have missed during the last week:

• Chris Adamson provides his own take on my interview with Richard Bair, particularly highlighting Richard’s statement that JavaFX is effectively Swing 2.0. This has also been picked up by Josh Fruhlinger at Javaworld.
• Devoxx has brought some news about the future of SwingX and Swing in JDK 7. As reported by Jan Haderka, Alexander Potochkin will be replacing Richard as the official SwingLabs project lead. In addition, some of the SwingLabs sub-projects will be part of JDK 7. This includes App Framework, JXLayer, Painters API and DatePicker. A gigantic missing piece is the BeansBinding, and this is already being queried by the community – update: see what Richard had to say about this. Another interesting piece is concerning the inclusion of painters, and how they will play with Nimbus’ own painters, as well as the level of possible customization of core Swing components.
• Christopher Deckers has announced release 0.9.7 of DJ Sweet project that aims to bring sophisticated components for SWT. The main focus in this release is the improvement of the Web Browser control, and the addition of a Flash Player with a simple API.
• Alexey Ushakov is the technical lead for JWebPane component, and he has finally revealed tentative availability schedule for this project. Contrary to my prediction, it looks that this component will be lightweight, providing Java2D-based implementation of WebKit painting hooks. Alexey’s comment on licensing issue is questionable at best, and has been discussed briefly by Remy Rakic.
• Alex Ruiz is writing about an interesting usage of FEST Swing library – to analyze the UI hierarchy of JavaFX applications.
• A few months ago there was significant blogosphere activity around using Swing as a foundation to build UIs in JVM-powered languages, such as JRuby, Scala, Jython and Groovy. Unfortunately only one camp has remained steadily active throughout the time – congratulations to Groovyheads for persisting in analyzing the deficiencies of pure Swing development and pushing the envelope. Danno Ferrin has announced release 0.1 beta of Griffon, and Andres Almiray writes about plugin support in Griffon. Andres is also busy experimenting with the builder support for both core Swing and third-party Swing components, and this weeks he has announced two new sub-projects, SwingPad and FlamingoBuilder.
• After last week’s entry on skinning the JScrollBar component, Ken Orr laments the lack of visual tools for assisting the creation of Swing look-and-feels and hopes to see the Nimbus designer released soon. In the comments, Remy Rakic speculates that it will be soon morphed into JavaFX designer.
• Jeremy Wood delves into Java2D, presenting an extensible implementation of charcoal stroke.

And now for the spotlight of the week. Java IDEs such as NetBeans and IDEA has frequently been quoted as examples of large Swing based applications. In the consumer-facing market, perhaps the most widely used application is LimeWire. This week the developers of LimeWire have announced the first alpha drop of the next release. The first two blog entries are out, and hopefully will be followed by more details on the technical implementation and integration of such libraries as SwingX components and painters, Glazed Lists, MigLayout and XULRunner. Click on the thumbnail to see a larger screenshot of LimeWire 5.0alpha.

Here are some Swing links that you might have missed during the last week:

• Gregg Bolinger combines two projects, JavaBuilders and client-objects, to enable automatic data-binding in YAML-driven Swing and SWT applications.
• InfoQ’s Charles Humble shares his thoughts on SwingX and core Swing in his followup to my earlier entry.
• The client heavyweight Joe Winchester wonders whether Swing should provide a way to automatically detect and flag long-running I/O operations that are blocking the UI thread. While i showed techniques for tracing long-running EDT operations before, Swing (and any other UI toolkit, as a matter of fact) could benefit greatly by making sure that programmers don’t shoot themselves in the foot. SWT does this to some extent by throwing exceptions on any UI related operation happening outside the UI thread. Substance closes some of the core Swing gaps by throwing runtime exceptions on component creation and some model changes – a move that has so far generated the most user resistance.
• Eugene Ryzhikov shares a tip on minimizing maintenance of table models.
• Piet Blok dives deeper into the JXLayer project and shows how to use it to create a generic ZoomUI functionality.
• Ken Orr keeps the promise and has started a series on skinning the scroll bar component.

Quite a few releases announced this week:

• Richard Kennard has published a LiveDemo of his MetaWidget project that allows you to start playing and coding with the project.
• Deane Richan has announced the availability of HTML TableLayout project that was previously part of the Xito Dialog project. It is rather unfortunate that (as usual) the comments section quickly degenerates into “i prefer” discussion of other layout managers.
• Manuel Kaess has published AlbumPlayer, a new cross-platform Swing-based media player.
• Clemens Eisserer has released version 0.6 of his JXRenderMark benchmark to measure the performance of his XRender pipeline for accelerating Java2D performance.
• Jean Francois Poilpret has announced the final release 1.0 of the DesignGridLayout project.
• Alex Ruiz has announced release candidate for version 1.0 of FEST-Swing UI testing library.

Devoxx 2008 has started today, and it has a few Swing related presentations:

• Jeanette Winzenburg on SwingX
• Richard Bair and Jan Haderka on SwingLabs
• Alexander Potochkin on JXLayer
• Maxim Zakharenkov on Swing Explorer
• James Williams on Griffon
• David Gilbert on JFreeChart
• Michael Huttermann on UI testing

With not a single feature from my JavaFX “look forward to” list available in the first release, it’s time to see what Sun is going to announce at Devoxx. Over the last few weeks there has been significant (in number of dozens) amount of submitted and closed bug reports in integration between heavyweight and lightweight components for the first two builds of 6u12. Risking yet another prediction (the one about JDK / module / OSGi was quite right, and the main discrepancies are already being criticized by the OSGi community), i would say that the web browser component is in the works, but as a heavyweight implementation. This would require closer cooperation with the (lightweight) rest of the UI toolkit. Share your thoughts in the comments.

In this interview Richard Bair answers my questions on Swing, SwingX, JavaFX and Java on the desktop in general, saving some of the announcements for the next week’s Devoxx conference. We wanted to do this interview immediately after my thoughts on the state of core Swing, but the JavaFX release has postponed it up until now.

Tell us a little bit about yourself.

Like many developers I know, I started programming because I wanted to write games. Somewhere along the line my dad convinced me to write him a database backed application for his business, and that’s how I got started.

Since then I’ve been predominantly an application developer. It was in that role that I started working with open source software, and eventually started working with JDNC. I was subsequently hired by Sun and have been the SwingLabs lead since that time.

It hasn’t been all smooth, I learned a lot about open source community building as I went along, and certainly have plenty of faults in getting SwingX releases out regularly. But my overall goal and desire has always been to make building real world applications easier.

I know in the recent past I’ve been involved a lot in Java demos and such that are consumer in nature. I like building applications, either consumer or enterprise. Consumer applications are closer to what got me started in programming in the first place, while enterprise apps are really where I cut my teeth (one of a handful of engineers I’m sure who love both big iron databases and pushing pixels ;-)).

Why was SwingLabs created, how did it evolve and what is its current state?

SwingLabs was a bold attempt by the Java Client Group to engage the open source community long before OpenJDK came along. Originally the brainchild of Amy Fowler and Hans Muller (and probably others on the team), the idea was to have an open source venue for building APIs that fill in the missing pieces of what is shipped with Swing.

As any Swing developer can attest, you have to build a lot of plumbing to build real apps with Swing today as shipped with the JDK. In the last few years a great many open source projects have been created to help fill these gaps.

SwingLabs was also designed as a place where these APIs and experiments could be vetted and included in the JDK. Our score in this regard is not so good. We pulled in a lot from the JDIC project, and we pulled some of the filtering and sorting work in.

We will be pulling more for JDK 7 as well, expect to see 2 or 3 components at least and also one or two big JSRs.

SwingLabs is currently run predominantly by the community which is really working I think pretty well. The dedication of our team of open source developers is a credit to them and to the open source reality that we live in.

We do need more involvement from the Sun side, and will be making an announcement in this direction at Devoxx next week.

If you were to start over with SwingLabs / SwingX, what would be the most important parts in building and maintaining the community involvement?

Regular releases. Regular content added to the SwingLabs.org website. More responsive bug fixes (my fault entirely).

Would you like to provide your side of the story behind the decision on the layers and painters in SwingX?

The fundamental idea behind painters was to decouple the rendering of components from the components themselves, such that you wouldn’t have to subclass the component to change its rendering (or replace its LAF which is a much more complicated proposition). The corollary was that there could be a collection of default painters that people could reuse.

There was an argument made primarily by Mikael Grev who had a similar API in his MIG Calender component (if I remember correctly) that we should have components that support painters to have an arbitrary sequence of painters. Sort of like JLayeredPane but for painters. I know Scott, Romain, Josh, and I didn’t particularly like it for technical reasons (which are all documented in the forums), and there was both support and skepticism from other people outside Sun.

At the end of the day, the project lead has to make a call on API, and I made the call I felt most comfortable with.

How likely is it to see the SwingX components being part of core Swing in JDK 7 and beyond?

All of them? Unlikely. Some of them? Extremely likely.

Originally Nimbus was planned to be developed under the SwingLabs roof, but was later put into the internal repository. Would you like to see the development of new Swing-specific functionality in the open before it gets put into the core distribution?

Nimbus is a special case. To properly implement Nimbus required a significant number of fixes and enhancements to BasicLookAndFeel, Synth (lots of bug fixes for Synth) and other core APIs and implementations. We simply could not have delivered Nimbus in the open source without these fixes. Also, Nimbus went into Java 6 Update 10 which was not part of OpenJDK. When Nimbus is forward ported to Java 7, it will be in OpenJDK.

I would prefer that all development was done as part of a community process, be it SwingLabs or an open JSR or OpenJDK.

Do you think that maintaining backwards compatibility has unnecessarily restricted the Swing team in moving this UI toolkit forward?

No I don’t. If you gave up backwards compatibility you’d have a whole other set of issues that are many times worse. The level of risk one developer is willing to take isn’t the same as another. For every one person who wishes we’d ditch backwards compatibility there are another 50 that would be violently opposed when that advice rendered their applications (or development of future versions of their applications) inoperable. Especially with a technology as mature as Swing.

To those people who say we should make a Swing2 which is not backwards compatible, I would say, this is exactly what we’re doing with JavaFX.

I also want to emphasize that Swing isn’t going away. We have a tremendous number of customers building Swing apps and that will obviously be supported and extended going forward. Also, we will allow you to mix JavaFX both into Swing apps and mix Swing in JavaFX.

Both Microsoft and Adobe view “line of business” applications as a very important target segment for their offerings (WPF, Silverlight, AIR, Flex). Is JavaFX only targeting the rich UI development (graphics, effects, animations), or do you plan to include modern business components such as pivot tables, grid trees and date pickers?

JavaFX 1.0 is oriented toward creative content, very similar to Silverlight 1.0. Future versions of JavaFX will be designed to also handle full blown enterprise rich client application development.

What effort is planned to be put into the core Swing in 2009?

We’ll have announcements for these plans at Devoxx.

Anything else you would like to add?

As an application developer, and as a toolkit developer, JavaFX is very exciting for me. The first release is really aimed at providing the foundation for all subsequent work. We’re focusing on animation, graphics, media, and related APIs with an eye towards the future so that we have a solid foundation upon which to add user interface Controls, frameworks etc. JavaFX gives us the freedom to design the best possible design we can, without any API backwards compatibility constraints. It really is an exciting opportunity. We’re committed to providing interop between FX and Swing so that people can build the kinds of applications they want to, and can mix and match the two.

Here are some Swing links that you might have missed during the last week:

• Jeremy Wood has been a busy blogger this week. First, he compares different approaches in using spinners for specifying length measurements in different units. Next, he presents a dialog to layout several tiles / cells on a print page. And finally, he closes the week with a partial implementation of Mac “Windows” menu that tracks the list of currently open top-level windows and their respective states.
• Olivier Gout has a prototype of WYSIWYG theme designer for Nimbus. The “official” Nimbus designer promised at this year’s JavaOne is nowhere in sight, and only time will tell whether this new attempt will outlive the growing list of Synth designers / builders mentioned in Swing Links of the Week edition of March 23, 2008.
• Patrick Ahlbrecht has a skeleton implementation of persisting window geometry and toolbar location between successive launches of an application window.
• Kai Toedter has written a demo application that shows how to use OSGi Declarative Services (DS) and Spring Dynamic Modules (Spring DM) together with Swing UI (and the Swing Application Framework, JSR 296). The Person Manager project is licensed under EPL.
• William Chen has announced his work on the Visual Swing Designer for Eclipse.
• Adam Bien continues to favor Swing over SWT in his two-part attack. Starting with how to make your Swing coding more efficient, he then continues to address the perceived Swing weak spots. From reading these and previous postings, looks like Adam holds a particular dislike towards SWT tables, and i couldn’t disagree more. Just like it takes quite some time to fully understand your way around Swing tables (including models, renderers, editors, listeners and much more), it takes a little bit more than a few suggested hours to switch to the SWT / JFace approach. This is not to say that one is clearly better than the other. It’s just that if you come with prejudice or a very strong knowledge in one, the other will seem clunky, over engineered and convoluted.
• Two interesting Swing-related threads on the Google group for Javaposse. The first addresses the misunderstanding of the painters issue and the community handling throughout the entire process, and the second calls for community questions on JavaFX.
• Andres Almiray has announced release 2.0.1 of JIDE Builder and 0.1 beta release of GfxPad.
• Roman Kennke continues his work with Java2D, writing about first Java2D pipeline implementation on top of the DirectFB hardware abstraction layer.
• Ken Orr has announced release 0.9.3 of Mac Widgets for Java. Major new addition in this release – iApp style scroll bars. Is it me, or is the reflection of the new scroll bars incorrectly flipped?
• Clemens Eisserer reports that his XRender pipeline has been integrated into the IcedTea fully open sourced port of OpenJDK.

In three days, JavaFX Desktop 1.0 will be officially released. I have been skeptical about JavaFX over the last few months, and while this may be attributed to general inclination of programmers towards being “entrenched” in the technologies that they know, there are other reasons as well. Aside from a few unnamed technology partners that were participating in shaping the capabilities of this release, the community has been effectively shut from lending its hand in commenting, testing and evolving the platform. We have long heard about “being blown away” by the new functionality being brought by JavaFX to the RIA market, and this week we will finally see if it is going to live up to the marketing hype.

Personally, i will be very glad to see at least one out of the following ten items being available for JavaFX, as well as cross-platform Swing applications come December 4:

1. 6u10 / 6u11 for Apple – [update] see bug 6761033 for some interesting news.
2. Full java lightweight rendering of SWF files even without installed Flash engine
3. Full java lightweight rendering of H.264 files even without installed codecs
4. Adaptive video streaming based on the client CPU and network utilization
5. Video capture and creation
6. Fully skinnable lightweight browser component based on WebKit or Mozilla / Gecko
7. Inclusion of form-oriented layout manager
8. Support for high level shader language (HLSL) for hardware accelerated custom effects
9. Nimbus designer
10. JavaFX.com with JavaFX-only applet driven content

And is it me, or are we going to see Sun ditching its own module initiative and move towards restructuring JDK as a collection of OSGI bundles?