On my recent flight to Germany, every time the flight attendant gave me food or drink, she would say "Enjoy it!". It's not just the words; someone asking you to enjoy your meal may be very polite. But it was the tone she struck that would brook no dissent; I must enjoy the meal .... or else. And when you're flying at 35000 feet for 10 hours you really don't want to upset the flight attendant.

I spoke a couple of weeks ago at the JAX conference in Frankfurt, Germany. I gave a couple of talks on Desktop Client technologies to enthusiastic audiences. My main session was well-attended, with a few people even standing in the aisles (I like to believe that it was because there were no more chairs left, although maybe it was just that they'd had a lot of coffee and could not sit down). I was especially pleased to have lots of people in my BOF at night; it's hard enough to draw a crowd to a talk at 9 PM, but when there's a band and free beer downstairs, it's particularly tricky.

There was a lot of great discussion at the talks. I won't cover all of the wide-ranging questions or topics, but it's worth mentioning some of the more generally applicable topics. In particular, the longest discussion started with "Swing needs patterns". This topic came up at the start of the BOF q&a session and dominated the rest of the session (which ran over a good 45 minutes ... while there was still free beer available downstairs!)

The word "patterns" is, I feel, overused and ripe for satire. A literal definition here might be "documentation and terminology that describes how typical application and coding practices with Swing should be executed." In reality, when people say "patterns" they mean anything from the more academic definition above to better sample programs to blueprints to beefed-up JavaDocs to tools that enable quicker development to framework classes that jump-start application development.

I think there is a bit of Methodology Envy here; one of the first justifications I hear for Patterns in client development is "they have so many patterns for server-side development!". What I cannot yet puzzle out here (being a purely client-side graphics geek and pretty unknowledgeable about server-side technologies) is whether these application development models are really comparable. Is the fact that they have patterns on the server side an indication that we should have them as well? Are patterns generally a Good Thing? Or are they necessary in certain types of situations (which may be more prevalent on the server side than the client side)? Did patterns evolve on the server side out of good responsible technology evolution? Or were they a necessity for a complex and quickly-changing world? (I swear, between servlets, struts, tiers, EJBs, JFC, app servers, J2EE, and the myriad of other acronyms and technologies over there I don't know how developers can avoid simply thrashing on trying to figure out what they're supposed to use). Does the programming model on the server side lend itself to patterns more easily than that on the client side? Or are we on the client side just too interested in visual functionality (being the graphics geeks that we are) and are we just ignoring the inevitable necessity of patterns in our code?

Part of the "patterns" argument relates to language and understanding. There's a great quote in an old David Byrne flick, "True Stories" (recalled to me by Hans Muller; my brain cells from the 80's have been recycled many times since then): "You know ... things that have never had names before are now easily described. [pause] It makes conversation easy." The line is great, as is the overall movie. (Quirky, but great - check it out if you haven't seen it yet). And although there's a dose of irony and sarcasm in every word in the movie, there's also a kernel of obvious truth; naming things makes talking about them easier. To reel it back in to the topic here, naming "patterns" of development can make conversations about otherwise complex topics easier. For example, if someone says Factory, I know what they mean without them having to describe how the Factory pattern works. If they start talking about some of the less common patterns, I'll probably lose touch with the conversation and drift off, but I can at least see the sense in establishing names and conventions for very common practices.

Someone had a pretty good example of why patterns are useful; there are common cases of bad coding practice in Swing that they could help prevent. For example, much of the "Swing is slow" reputation comes from applications that execute long-running methods on the GUI thread (such as querying the database over the network in the middle of your mouse clicked method). This is obviously a Bad Idea, and it's one that we preach against with regularity in articles and JavaOne talks. But if someone has not read the right article or attended the right talk or thought through the problem thoroughly, it is not immediately obvious why this has the horrible frozen-GUI effect that it does. What if there were a clear pattern we could point people to that solved this problem? Then there would be defined terminology here (maybe we could call it the "Offload Business Logic Operations Or You Are Screwed (OBLOOYAS)" pattern) that people could quickly digest and propagate. And if the pattern were concisely described with sample approaches to fix the problem (such as SwingWorker), then they would not only understand the problem, but also the fix, and they would probably stand a better chance of never having the problem, or at least of fixing the problem in short order if they stumbled across it.

Another example that someone brought up is one of code consistency. Since there are no clear standard ways of writing different parts of Swing applications, the ways that applications get written are infinitely varied. This contributes to code maintenance problems as developers swap into and out of projects, problems when some developers do not understand some of the implicit ways to do or not do things (such as the OBLOOYAS pattern above), and general problems of coding consistency. If there were clear patterns of how to construct various parts of client applications, then the code could be simpler and better overall and lead to more powerful and maintainable applications.

In the wider sense of "patterns", where people actually mean "I want Swing development to be easier", what people tend to look for are frameworks that can assist in application development, especially for large applications. This can be anything from good sample code that people can cut and paste from to tools that have code- production wizards. Some examples of these gotta-have-but-tedious-to-figure-out-and-write elements of Real World applications include lazy loading, splashscreens, asynchronous operations, status and error reporting, internationalization, accessibility, error recovery, context-sensitive help, and persistent configuration preferences. Also of interest in larger-scale applications are things like plugin frameworks and scripting support. There are examples of frameworks out in the wild, although solid frameworks for Swing in particular are not yet in existence (or at least not standardized). The JDNC project is an attempt to make some elements of enterprise application development easier, but we should probably go further in simplifying Swing development overall.

In any case, I think the main message here is clear; we need to do more to make large-scale desktop application development easier and better.

Other interesting topics that came up in my sessions included:

• Swing books: Someone asked for a "Swing Performance" book, or at least some chapters on Swing in an overall platform performance book. Apparently there were some useful chapters in a book published a few years ago (I believe he was talking about Steve Wilson's and Jeff Kesselman's book), but nothing since.
• Look & Feel Chooser: Someone asked if we could come up with a standard "Look & Feel Chooser", similar to JFileChooser. He said that applications which allow users to choose the look & feel of the application all roll their own solution, and he thought it would help standardize this by having such a thing supplied by Sun. I said that it seemed like something that most users may not actually care about or understand, so it didn't seem (to me) like something that most applications would want (and thus would not make sense for us to supply in core Swing). Anyone else feel strongly about this?
• Modality: Someone said that his application had weird/unexpected/undesired modal behavior. His app had 2 windows and a dialog on one window would disable input for both windows instead of only one window. Happily, this problem is resolved in Mustang; AWT has introduced new modes that should address this.
SecurityManager disabling: Someone asked whether it was possible to start JNLP applications without a security manager. He understood why SecurityManagers are enabled by default, but in his case he is developing an application for enterprise deployment where the runtime situation can be trusted (similar to local applications, for example). He did not like the startup penalty imposed by the SecurityManager and hoped to avoid that by disabling it for this known situation.
There is only possible solution here; he could disable the SecurityManager by calling System.setSecurityManager(), but please note that this is not recommended as a general solution.
Of course, another possible fix here is to make the SecurityManager implementation faster (yes, we continue to look at both startup and runtime performance, so hopefully things like this do continue to improve over time).
• Swing Tutorial should address responsiveness: Someone thought that the information about Swing responsiveness (such as the "OBLOOYAS" diatribe above) should be part of the JFC Tutorial. Actually, the latest version of the tutorial does address some of this more than the previous version (although we could still go further).

How about you? Think we need "patterns"? Or frameworks? Any concrete examples for me? Or things you would like to see done here?