Hans Muller's Blog

JSR 296 Bows - Swing Application Framework

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.

Comments

• Outstanding!

  Excellent work, for both the demo, and the project. People are really going to start having a lot of fun with WebStart too!

  Also, highest regards for having it run untrusted. This sets an important precedent.

  Posted by: cajo on June 02, 2006 at 12:35 PM

• Nice presentation. Just want to add that from my experience, many Swing application are very messy because developers mix together orthogonal aspects of the applciation. For instance, GUI, validation and persistance "services". Having a small core with pluggable services which by design has access to GUI has proved to be useful. Another useful thing would be Hierarchical MVC approach which would extend widget level MVC to the macro application level.

  Posted by: pinocio on June 02, 2006 at 01:46 PM

• When I first heard about this API, I was encouraged that it aimed to address needs much simpler than a heavy RCP platform yet handle a lot of boilerplate code. I have already implemented a proprietary API along these lines, I'm currently aiming to get it open-sourced, and maybe have something to contribute... In any case, for me (and I imagine a whole load of other developers in similar situations), it's easy to recognise the use-cases addressed by your proposed API.
  The action mappings using resource bundles are fine but perhaps a little limited: for example, it can be useful sometimes to look up localization data from a database and not from a hard-coded resource file.
  With regards to actions that block, what's the relationship with the new modality API in mustang? The options NONE, WINDOW, and APPLICATION would seem to depend on it, but that's not easy to implement on JDK 1.4 and 5.
  With regards to the shutdown milestone, will it handle shutdown signals (such as CTRL+C under windows, normally intercepted with shutdown hooks).
  - Chris

  Posted by: chris_e_brown on June 02, 2006 at 02:23 PM

• I forgot to enquire about support for accessibilty (for disabled users for example). I may have skipped over that, is anything provided for these users?
  - Chris

  Posted by: chris_e_brown on June 02, 2006 at 02:43 PM

• Same here on the Mac OS X error. Is it possible that you compiled using Mustang?

  Posted by: evickroy on June 02, 2006 at 10:28 PM

• Dear Hans,
  For a simple application framework that lets you run the same code either as an application or an applet, please check out lafros.com/juice.

  Posted by: lafros on June 03, 2006 at 03:04 AM

• 
  I've deleted the comment from robogeek that begins:

  "On Intel OS X with Java 5, I get a dialog saying it
  crashed the Java Cache Viewer."

  There wasn't away to just elide the giant stack dump that followed,
  which was useful but rather large. I've saved the complete text and
  we've been able to reproduce the OSX bug that was also reported by
  evickory. I'm trying to figure out what's going on and will post an
  update as soon as I can get someone to verify a fix (I don't have
  a Mac). Sorry about the bug and, robogeek, sorry about messing with
  your post.
  

  Posted by: hansmuller on June 03, 2006 at 09:23 AM

• I got a OS X (10.4, Java build 1.5.0_06-112 for me) error also, but I found that it runs OK with javaws http://www.java.net/download/javadesktop/blogs/hansmuller/jsr296-bows/zarathustra.jnlp from a terminal window.
  

  Posted by: jtr on June 03, 2006 at 10:12 AM

• 
  The web started demo now appears to launch correctly on OSX.

  
  Based on a dose of just-in-time help from Josh Marinacci, I've removed
  some JNLP boilerplate generated by the Java Web Start NetBeans plugin:
  the download="eager" specified for each jar in the resources
  section and the icon href="default" element from the
  information section. This stuff seems to cause the OSX web start
  implementation to keel over. I will follow up with my colleagues at
  Apple to see what's going on, next week.

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

• There's also another framework that is using annotations with Swing in a very nice way:APTFramework

  Posted by: amohombe3 on June 04, 2006 at 07:02 AM

• Hi Hans,

  I know it's a little off-topic, but I just wanted to ask which of JavaSound or JMF you used for your application, and whether there were any tricks to getting sound output in an unsigned WebStart app?

  Thanks,

  Graham.

  Posted by: grlea on June 04, 2006 at 08:17 PM

• Why now?Pardon me for my philosophical bent Hans; But why now?Why is now the time for the JCP to annoint a Swing application framework? Is this something that has only now become necessary, or is this something that should have been defined long ago?Please don't take this question as a negative attitude towards your proposal... I think it's a great idea, just curious on the timing.-JohnR

  Posted by: johnreynolds on June 05, 2006 at 07:09 AM

• Hans,
  I like the presentation and your proposal. I like the minimalist approach that you're advocating. Do you have any plans for making a Preferences widget? This would definitely make it easier to make professional looking apps.

  Is there going to be a simple way to develop forms? I know that the SwingX framework has a JNForm, it would be nice if there were some simple way of defining a form, perhaps using annotations to handle the binding.

  Is some thought being given to the number of cognitive leaps that a developer must take in order to use the framework? There are going to be developers who are new to Swing, and who may or may not have had any experience with Struts/JSF. How will those developers learn this framework quickly?

  With respect to JSF, the focus was very much on toolability, but not really on basic usability. My hope is that you'll keep that in mind as you go forward, and ask yourself, how well the API can be used, if you're not using Matisse, or any other GUI builder for that matter.

  Regards,

  Mark
  

  Posted by: phidias on June 05, 2006 at 09:31 AM

• 
  [response to Chris Brown] Per looking up Action attributes in ResourceBundles: I agree that it's useful to be able to use a database for the backing store for resources. ResourceBundles can be defined with a class, isn't that sufficient for looking up resources in a DB? In the examples I've written I've always used properties file ResourceBundles because most developers are perplexed by anything else. However there is a standard XML format for properties files, and by using classes, you can pretty much bridge to anything.

  
  We do have a goal of supporting the app framework on Tiger, and you're correct in pointing out that the blocking Action mirrors the new support in Mustang. Not sure how to handle that yet. Likewise for handling native shutdown signals (like ^C) gracefully and in terms of the framework API.

  
  On accessibility: presently there isn't explicit support for accessibility in the framework API. The support for injecting resources into a component hierarchy might make it more likely that this kind of work gets done.

  Posted by: hansmuller on June 05, 2006 at 10:33 AM

• [response to Graham Lea] I used the used the JLayer (pure
  Java!) MP3 player library to play the soundtrack. It's running
  on a background thread and I made no attempt to synchronize it with
  the slideshow, other than launching the background thread when the
  animation starts. There are doubtless more sophisticated ways to do
  this and a little synchronization wouldn't have hurt. On the upside,
  the JLayer library was trivially easy to use and the timing seems to
  (roughly) work out on different machines.

  Posted by: hansmuller on June 05, 2006 at 10:41 AM

• 
  [response to John Reynolds]I suspect we should have created an
  application framework for Swing years ago. Not having one has been an
  obstacle to adoption and it's limited our ability to share best
  practices in the application realm. I think I spent five minutes on
  this particular lament during my JavaOne session. That said, it's
  still a very worthwhile project and there's a quote (Will Rogers?)
  that sums up the way I feel about it pretty nicely: "don't let
  yesterday use up too much of today". So we'll do it now, and
  hopefully have a little fun while we're at it.

  
  

  Posted by: hansmuller on June 05, 2006 at 10:56 AM

• 
  [response to Mark Fortner (phidias)] I don't anticipate
  providing generic Forms or Preferences components in the app
  framework. High level components like that are important, however I
  think it's more important for the app framework to make it easy to
  incorporate them than to define them. I would hope that the SwingLabs
  project, and eventually perhaps Java itself, would be the source of
  essential components like the ones you've mentioned.

  
  As far as data binding goes, I hope you'll take a look at JSR 295.
  Scott Violet is the spec lead, and he's been writing about it in his
  blog: http://weblogs.java.net/blog/zixle/.

  
  I completely agree with you about limiting the number of "congnitive
  leaps" and, similarly, not focusing exclusively on ease of use via
  tools.

  
  

  Posted by: hansmuller on June 05, 2006 at 11:16 AM

• Excellent! It was about time to have some sort of guidelines or even a framework!
  I hope this initiative and the JDNC - Swinglabs stuff to be soon available and ready to go for the majority of developers!

  Keep up the good work!

  Posted by: javaneze on June 06, 2006 at 02:11 AM

• Ethan Nicholas's blog touches upon the issue I have with resource bundles: for one component for example, you have multiple "facets". You have the text, a tooltip, an accessible name, an accessible description, a mnemonic, an accelerator keypress, a menu icon, a toolbar icon, and so on. Translations need to be well co-ordinated (mnemonics and labels are good candidates), and property resource bundles are easily messed up through have a separate property-per-facet.
  Going on from this, another shortcoming of simple property resource bundles is that the text is fixed. It's very common to have the main application window with a title like this:
  My application <version> - <filename>
  ...and JLabels are commonly defined in this way for example (at least, in my experience). I generally adopt a solution whereby the externalized string can either be literally pasted as-is into the UI with a lightweight framework, or can be merged with template data (using say MessageFormat).
  One solution I've implemented is using a custom XML format, just a little more sophisticated than an XML properties file, where "UI items" are defined and broken down into these facets (including arbitrary base64-encoded binary data, such as image icons).
  Hope that helps contribute some useful ideas.
  - Chris

  Posted by: chris_e_brown on June 06, 2006 at 04:42 AM

• Chris - I typically address the "My application <version> - <filename>" issue by allowing messages to include other messages via curly braces, ie.:

  application.name = FooApp
  application.version = 1.0
  application.title = {application.name} {application.version} - {0}

  The {0} (for the filename) is filled in using a MessageFormat. The API call would be something along the lines of Util.msg("application.title", currentFile.getPath()). (The MessageFormat parameters are varargs, so you can include any number of them, and there is a variant which only takes the message key, for static messages). Does that sound about right?

  Posted by: enicholas on June 06, 2006 at 05:36 AM

• For an alternative approach to the underlying issues addressed by JSR 296 (and also in a way JSR 295), check out Superficial. Its novel architecture takes some getting used to, but it does demonstrate the feasibility of a framework to manage the GUI and content of quite elaborate desktop applications.

  Posted by: dimwight on June 06, 2006 at 08:04 AM

• enicholas - yes, that's along the lines of the approach I use, in both definition and use, including recursive properties. Having said that, the JavaDocs for MessageFormat specify that it's limited to 10 arguments (ArgumentIndex can be in the range 0-9), so that's a constraint (that I've fortunately managed to avoid in nearly all scenarios).
  - Chris

  Posted by: chris_e_brown on June 06, 2006 at 10:03 AM

• My dear Hans,
  Q: How can one improve on perfection ? A: Only by inserting a Dolphin
  between the reptile and the primate.
  - Danny
  

  Posted by: dannyc on June 06, 2006 at 12:57 PM

• 
  [response to Chris Brown, Ethan Nicholas] I've also found it
  useful to be able to combine string values defined by naming other
  resources. I found overloading the MessageFormat "{n}" parameter
  syntax a little confusing, so I was thinking of using the Java EL
  syntax for lookup instead. It's quite similar and resonates with Unix
  shell programmers. That would make the example:

  application.title = ${application.name} ${application.version} - {0}

  Posted by: hansmuller on June 06, 2006 at 01:01 PM

• My dear Hans,
  Q: How can one improve on perfection ? A: Only by inserting a Dolphin
  between the reptile and the primate.
  - Danny
  

  Posted by: dannyc on June 06, 2006 at 01:02 PM

• 
  [response to dannyc] You almost caught me. For a moment, I considered
  finding a picture of Flipper and slapping it into the demo and maybe
  adjusting the timing so it appeared during an appropriate crescendo.
  Ha! Just this once, I'm going to stay away from straying away from
  today's task. Which is not fooling around with the demo. Or writing
  about it. Oops.

  Posted by: hansmuller on June 06, 2006 at 01:13 PM

• Hans,

  I look forward to seeing where the great work you showed at JavaOne goes.

  I am curious about your "research" on the size of the average Java app. (We talked about this briefly at JavaOne). I agree, the average is smaller than an IDE, but I think the average is a bigger than most may suspect. I'd love to see a poll on javadesktop.org asking what the average number of screens is in the apps people are writing (and more formal research teasing out "toys" that people whip together). I suspect the average is closer to 50 or 100 than 10. A manager at my client was stunned when I told him his app had over 100 dialogs (and dialogs were considered unimportant relative to what they call "views.")

  Consider Swing Sightings - these are pretty large on the whole. The "sightings" you don't see are internal apps, which are more common since they are better suited to Swing because the deployment and installation is more easily controlled. Then consider that even small apps need similar client side services as large ones. Certainly the existing RCP's (ecept Spring RCP) are overkill in some ways, but certainly there are a pletora of problems even simple apps solve. I wonder how the tradeoff of simplicity and usefulness will pan out.

  Michael

  Posted by: michaelbushe on June 09, 2006 at 12:35 PM

• Hans,
  Can you keep us updated on the OS X bug? It appears that this actually did corrupt my webstart cache to some extent. I can run new webstarted apps, but I can no longer access the cache viewer. When I try to, it continues to report that the cache is corrupt. This is a major pain since you have to manually remove a java.net webstarted app from your cache in order to pickup a newer version due to some limitations/issues imposed by java.net.

  Thanks
  Erik

  Posted by: evickroy on June 11, 2006 at 08:41 PM

• 
  [response to Michael Bushe]As you know, my guesses about size
  distribution of Swing applications aren't based on anything like
  statistically significant survey data. I'd be surprised if the
  average Swing application had more than 50 screens, but not terribly
  surprised. I'd be very surprised if the average Swing application
  project was staffed more than 10 developers, and similarly surprised
  if the average project incorporated more than 50 loosely coupled,
  independently developed, modules. A survey would be interesting.

  Posted by: hansmuller on June 13, 2006 at 03:35 PM

• 
  [response to evickroy] Here's a bug update.

  
  I ran into two serious bugs as part of building this demo app. Both
  were due to interactions between the NetBeans Java Web Start plugin
  and the Java platform. The first occurred when I tried testing the
  app by launching it (via JWS) from within NetBeans:

  
  6434589 JNLPClassLoader fails to find resource in another jar using file:// protocol

  
  This doesn't occur when the app is deployed normally, since resources
  are loaded from the jar file in that case. The bug isn't in the
  public bug database (http://bugs.sun.com/bugdatabase/), I assume
  that's because the fix has a security aspect.

  
  The other bug was that the boilerplate JNLP file generated by the JWS
  plugin caused the JWS cache to become corrupted on the Mac, and that
  triggered bug 4991466
  (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4991466)

  
  4991466 application cannot launch anymore if resources in cached is corrupted

  
  The JNLP file culprits were the empty icon element and/or the
  download="eager" attributes in the original JNLP file:

  
  <icon href="default"/>
  <resources>
  <jar download="eager" href="Zarathustra.jar" main="true"/>
  <jar download="eager" href="AppFramework.jar" />
  ...
  </resources>

  
  Clearly the plugin shouldn't generate boilerplate that causes the OSX
  JWS implementation to corrupt its cache. And it's also true that the
  Mac JWS implementation shouldn't do that. There aren't bug IDs for
  this yet; when there are, I will post them.

  Posted by: hansmuller on June 13, 2006 at 03:38 PM

• Hi, I could not read all the comments here, but I am very interested on this JSR. There is one point that is annoying me: why limit the JSR to Swing? Swing is just a small part of a Java application that uses Swing ("desktop application"). Application life-cycle, resources management, preferences, data access, validation and application logic (MVP) are all "widget framework" independent. No matter whether the application uses AWT, Swing or SWT, it will need to address this issues. As it would be very strange to import a "javax.swing.application" in a SWT application, I think there is two ways to follow: (a) broaden the JSR making it at least partly independent from Swing or (b) complementing the JSR with other JSRs or even third party frameworks. I myself am working on a simple MVP framework, so maybe alternative (b) is the answer. Keep up the good work!

  Posted by: diegomrosa on June 20, 2006 at 06:44 AM

• [OSX JWS cache corruption bug]
  Just to complete the bug reporting, an issue - 77862 - has has been
  filed against NetBeans: Java Web Start plugin crush [sic] in Mac os.
  The problem is, as reported earlier, that an empty icon element () in a JNLP file, will cause the OSX Java Web Start
  implementation to corrupt its cache. That prevents the app from
  launching and appears to permanently disable JWS until the cache has
  been cleared manually. There's no need for the NetBeans plugin to
  generate this empty element, so I would hope that a fix emerges
  promptly. Unfortunately, the bug currently has only been giving
  middling priority. More here:
  http://www.netbeans.org/issues/show_bug.cgi?id=77862.
  

  Posted by: hansmuller on June 20, 2006 at 10:39 AM

• For fun, I was implementing parts of this framework based on your slides. I have what may be a silly question: How does the shutdown method get called. Your slides state that it is called on the EDT. I don't see any way that you get access to the application's JFrame in order to attach a traditional window listener. Are you planning to hook into the EventQueue to listen for window closing events?

  What am I missing?

  Posted by: diverson on June 27, 2006 at 01:06 PM

• Dear Hans,

  Maybe its too early to ask this, but the following questions popped up while I browsed the presentation styles:

  Will there be support for the Mac OS X document-based application archetype? Or will you only support application archetypes for Windows and Unix (i.e. MDI, SDI)?

  Does the Application framework separate the document interface from the application logic, so that one can reuse the same application logic with an SDI, an MDI or ADI archetype?

  Posted by: wrandelshofer on July 02, 2006 at 03:37 AM

• Hi Hans, JSR 296 looks to be in good hands. It may be more weight than you are prepared to consider, but I urge you to take a look at https://sam.dev.java.net/ which has a rich XML-based Actions management framework based in part on Mark Davidson's code.

  It handles the mechanics of defining actions, merging actions into existing action-lists, handling subclasses of JToggleButton, and building menu, toolbar and popupmenu. It should be orthogonal to most of what you're defining (except for the resource-based action definitions) but it would be even better if it was an approved part of the JSR.

  Best of luck with the JSR and the ongoing evolution of the Java/Desktop platform.

  Colm.

  Posted by: colmsmyth on September 05, 2006 at 07:16 PM

• Hi Hans,
  JSR-296 IMHO concentrates too much on making the creation of new applications and too little on
  maintaining them after the initial implementation is complete.

  I believe JSR-296 should include a validation concept/framework.
  The concept that I use (whose origins are some 30 odd years old) is
  a level by level bottom up validation that detects and rectifies invalid
  data as early as possible.

  At the atomic component level (i.e. a javax.swing.JTextField) this is easy enough with
  vetoable listeners on a FocusLost, the problem is with containers (e.g. javax.swing.JPanel)
  that do not directly hold the focus.

  Dave

  Posted by: dmgaskin on January 05, 2007 at 03:46 AM

• I strongly second the last post. The presentation model/UI toolkit separation would be of major help.
  Even if you are not interested in exchanging the toolkit.
  A rich client developer has enough to do with the pesentation logic. Even e.g. Netbeans has a hard time
  to make the JTable work reliable. Of course not the time a small development team can perform.
  That's one of the nice things I've seen (but not used) in JFace. Provide things a widget/window is
  working well with. This 80% working out of the box looks very promising.
  

  Posted by: wrostek on January 18, 2007 at 07:52 AM

• I think it's very important to consider using the existing JSF specification as a basis for this JSR. It would be great if you didn't need to care if the application you are developing is a web app or a rich client app.. Of course you don't want to give up functionality for rich client app so they are compatible with web app but for the most simple apps this transition should be possible.

  Posted by: garpinc on February 06, 2007 at 08:22 AM

This work is licensed under a Creative Commons License.