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
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
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.
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).
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).
How about you? Think we need "patterns"? Or frameworks? Any concrete examples for me? Or things you would like to see done here?