Sun has made two significant announcements recently in the Java desktop space: Java Desktop Integration Components (JDIC) (jdic.dev.java.net) and Java Desktop Network Components (JDNC) (jdnc.dev.java.net), both of which are open sourced under an LGPL.

JDIC
JDIC is essentially about allowing Swing access to more native platform resources, such as embedding the operating system's Web browser in a GUI, or enabling more control over taskbar support. I think the goal of elevating the function point of the end-user's experience, so that a Java application looks and behaves no differently for other desktop programs, is wonderful. I won't belabor the obvious point, but for me JDIC is a missed opportunity for bringing Swing and SWT toolkits closer together, as the latter already provides native embedded browser and taskbar support. Both toolkits have farther to travel along this road, as users demand more and more platform fidelity from their programs. All I sincerely hope, for Java's sake, is that the decision to forgo the chance to use the CPL open sourced SWT as the basis for JDIC was made for sound business reasons, not bruised egos.

JDNC
Java Desktop Network Components is a project that has always promised to be successful because its roots lie in trying to simplify the programming model of writing GUIs that connect to back-end databases or services. By implementing JDNC, developers have helpfully adopted a layered approach.

Swing Extensions
The extensions include new UI classes such as JXTable, JXTree, JXEditor, or JTreeTable. These extend the basic Swing toolkit to provide a set of controls that are designed out of the box to work with data. The JForm class, for example, is a nicely thought-out control that helps you easily create a data-bound set of components. What's nice about the Swing extensions is that they can be used without the rest of JDNC and, with the sorting and filtering enhancements, represent a nice turn of the crank for Swing that any GUI developer will hopefully benefit from. Another welcome feature is an overhaul of the way actions work, allowing more flexibility. I believe there might be plans to roll the Swing extension packages into a future release of J2SE. Such a move would be great for the general Swing developer and would provide a welcome set of base enhancements.

JDNC Components
These mirror the Swing extensions with the prefix JN, so for JXTable there is JNTable, JEditor has JNTable, and so on. These are standard JavaBeans so they should be easy to integrate into GUI builders and intuitive to Java programmers; however, rather than subclass their visual peers, they wrap them instead. I think this is a great decision, and is rooted in the desire to simplify the programming model that currently includes a lot of low-level properties for Swing controls. By using delegation, the API that's surfaced for the developer is one designed around the data binding and access capabilities of the control. There are some nice new listener interfaces as well, such as org.jdesktop.swing.event.ProgressSource that allows a DataSource to signal the progress and completion of a long-running task. The whole experience using the JNComponents shows that they have been well thought-out and well implemented.

JDNC Markup Language
The purpose of this layer is to allow the nonprogrammer to easily customize JDNC components using XML. One of the main benefits I can envisage with the XML configuration of components is not that the unskilled developer will use this in preference to cutting Java source code. Presumably, said person is going to be using a GUI builder-like tool that should be able to hide XML or Java implementations equally well. XML, however, offers the advantage of being easy to create and manipulate at runtime, so GUI behavior can be manipulated dynamically (perhaps the XML prepared by a servlet as the result of a user query) and less hard coding need occur in the actual client layer. One of the goals of any large business GUI application must be to capture as much as possible in rules and rely less on hard-coded, bespoke client screen logic. Having XML prepared by a rule engine that consumes a model definition of the application and serves this up to JDNC to implement the wiring logic might well be the answer. This could become a very powerful usage scenario.

Open Source
JDNC has been released as an open source project, which is interesting because it's outside the usual JSR/JCP process. I'm very encouraged by this, as I hope it will benefit from the rapid progress that other open source projects have enjoyed, and because the end users of JDNC are programmers trying to build business applications using Swing. It's an invitation for everyone who has done this for the last few years to bring the benefit of their knowledge, gripes, suggestions, and, ultimately, code to the table. If you've had to build your own data access framework on top of Swing, or wished one was there, I strongly encourage you to visit the JDNC homepage to become involved in the project and give the developers the benefit of your experience and ideas. I believe JDNC is one of the most exciting things to come along in the GUI space in any language for many years, and I think it has the potential to take Java client programming to a whole new level.