For the past five months or so, I've been working on a fledgling project to define an application framework for Swing.

Some people are highly organized. They set long and short term goals according to a stable set of priorities and then focus on nothing else but progress. These people, with their powerful work ethic and bulging resumes, are often successful. They get up every morning, attack the day's tasks, take stock of their progress, and then dream of how to get the job done just a little more efficiently in the morning. And after exactly 6 hours sleep, they do it all over again. These people get things done.

I am not these people. I admire their drive and their accomplishments, and sometimes I wave as their phalanx trots by. I could try and justify my own meandering progress by pointing out all the things that these people miss as they forge forward, shields on forearms, eyes straight ahead. But I will not, because the truth is that I'm just not highly organized. Not meant to be at the head of the V formation, with a list of the five things that must be done before sundown taped to the inside of my protective helmet. I'll be successful, but in doing so, I'll surprise everyone a little. Even me.

Earlier this year I spent some time studying the NetBeans and Eclipse IDE subsets that are referred to as "Rich Client Platforms". I was impressed by the scope of both frameworks and the evolving support for them in the corresponding tools. On the other hand, I was concerned by their complexity, and by the steep learning curve that new desktop application developers would face. Making a substantial investment in learning a rich client platform seems warranted when the application you're building roughly approximates the size and shape of a general purpose IDE. Similarly, if you're trying to marshall a very large loosely coupled engineering team, like the teams that have built NetBeans and Eclipse, then you'll find that the structure of these platforms help to organize the work. I don't think those situations are typical.

We've made a scientific survey of Swing developers and discovered that of the 2.5 jillion applications that have been written in the past 8 or 9 years, most of them are smaller than your average IDE. Most of them employ smaller teams and most of them are built by developers with less time and less experience then the authors of our big IDEs. I think we need to make it easier for the average developer to start the average application, and to finish it. To me that implies that a small desktop application framework is needed. Not a framework for small applications, but a framework that's small enough for a developer to understand after an hour's study.

That said, I don't think there's any value in trying to encapsulate or hide the underlying Java platform. That vast API landscape is vital to modern applications. Networking, threading, IO, GUI, graphics, XML, and all the rest are in there because they're essential to most applications. Perching an enormous application framework on top would only make the overall platform more intimidating. We surely don't want that.

Having decided that a narrowly focused application framework was a good idea, I immediately plotted a course for a prototype, and then, clipboard in hand, carpenter's pencil tucked behind my ear, I spent about two weeks building a multi-way split pane. It's not particularly easy to explain why this was the right next step to take. So I will not try. You can read the article and try the web started demos on java.net: MultiSplitPane: Multi-Way Splitting Without Nesting. Of course, if you do, you're demonstrating the same disorganized tendencies that led me to write it in the first place.

Thankfully, since then, two processes have kept me (mostly) on track. At JavaOne Scott Violet and I gave a technical session about the application framework prototype, and I've filed a JSR to cover the development of the API. The JavaOne session was A Simple Framework for Desktop Applications (TS-3399). Click on the link to download a PDF of the slides. I've also filed JSR 296, and on Tuesday May 15th, it was approved by the JCP executive committee. If you're interested in joining the JSR 296 expert group (EG), you can do so from the "I would like to join this Expert Group" link on the JSR 296 page. I'm setting up the EG now and hope to begin work in a few weeks. If all goes well, we'll produce reference implementations of the framework for Tiger and Mustang Java SE releases, and the framework will be incorporated in the next major SE release, code named Dolphin.

This blog is my way of publicly introducing the Swing Application project and JSR 296. As the expert group gets underway I hope to have a java.net project up an running that will contain snapshots of the evolving spec and implementation. I'd also like to host a set of smallish applications, built with the framework ofcourse, alongside the project. There's no better way to keep a framework project focused on real problems than by using it. So we'll do so, and as things stabilize, hopefully other developers will give the framework a test drive.

So I wrote all of the above on Monday (four days ago) and then I thought: it would be nice to conclude this announcement with a little demo app. Something amusing to reward the reader for slogging their way through all of this. So, I decided to create a little slide show, using Chet Haase's timing framwork , that displayed a few pictures in sync with some music. I used the JLayer (pure Java!) MP3 player library to play the Sunrise movement from Also Sprach Zarathustra (that's the opening theme from 2001: A Space Odyssey). Jeff Dinkins applied some magic to shorten the music to about 51 seconds, because we knew that none of you would have enough patience to listen to the complete minute and a half, when accompanied by my feeble photo montage. Finishing this project was supposed to have consumed an afternoon. Sadly, life imitates blog, and here it is Friday. On the upside, I managed to uncover a bad interaction (bug) between Mustang and the new NetBeans Java Web Start plugin. On the downside, after spending more hours than I'd care to admit trying to find the perfect sequence of photos on Flickr and Yahoo and Google, I've created the following bit of pretentious codswallop.

You'll need to make sure to turn up the VOLUME ON YOUR PC to hear the soundtrack. Dawn starts out dark, and it's not very interesting without the catchy music.

So, in closing, I'd like to thank the JCP executive committee for approving JSR 296. I'm working on getting the expert group sorted out right now. We have many more volunteers than we can handle and I appreciate the show of interest and support. Updates about JSR 296 progress will appear on javadesktop.org and often right here. So long as I stay focused.