Skip to main content

JSR 296 Bows - Swing Application Framework

Posted by hansmuller on June 2, 2006 at 10:18 AM PDT

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 href="http://weblogs.java.net/blog/hansmuller/archive/2006/03/multisplitpane.html">
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: href="http://today.java.net/pub/a/today/2006/03/23/multi-split-pane.html">
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 href="http://weblogs.java.net/blog/hansmuller/archive/ts-3399-final.pdf">
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.

darwin.jpg

Launch Button src="http://weblogs.java.net/blog/hansmuller/archive/jws-launch-button.png"
width="88"
height="23"
style="border-style:none"/>

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.