Symphonious

There was an interesting panel discussion at JavaOne today about the open sourcing of Java. The panel was made up of folks developing open source JVMs and a representative from Sun. Compatibility is obviously a common theme to these discussions and there were a number of mentions to just how bug for bug compatible the alternative JVMs are trying to be. It occurs to me though that if all the implementations wind up behaving in precisely the same way, there's not really any point to having multiple implementations. Yes multiple licenses are nice for particular niches but for the average Java developer, what's the benefit?

A reporter came up to me after the session (apparently I'd made some good comments) and asked about what benefits I saw. Her first question was about how useful having the source code would be. The trouble is, the source code for the standard Java class library has been available for as long as I can remember and open sourcing Java doesn't change the legality of copying and pasting code (unless your product is GPL) so there's no real advantage in source access. There are a few sun.* classes that now have source code available and didn't previously which can be useful but not overly so.

The other advantage is that was mentioned by the panel is that you can fix bugs for clients *now* instead of having to wait for the next release of Java. Of course, for the average developer this isn't really an option either because it would involve deploying the fixed JVM to all their customers. It might be feasible for people running controlled servers that just run their apps but it's unlikely to be practical very often. You could however add a workaround to your application for now and contribute a fix back to the JDK for the future which is likely to happen a fair bit.

One interesting aspect of contributing fixes back is that in a lot of ways, there is an incentive for companies not to contribute the fix back - they now have one less bug than their competitors. If the fix requires significant maintenance contributing it back is a pretty clear win, but many work arounds don't have any real need for maintenance. They might be in areas of code that are very infrequently changed, they might be modular enough to be quite separate etc.  Ephox products have a lot of work around for bugs in various browsers, JREs and OSs, many of which receive so little attention and maintenance that we can be surprised to find them years later, still working perfectly and still working around an unfixed bug (we do report these to Sun, but few people run into them so they tend to be low priority). The other consideration is that even if future versions of the JRE include the fix, you still can't remove the work around because the older JVMs are still in use by various clients, so you pay the maintenance price anyway.

There are other business considerations involved with the decision to contribute to the JDK as well - you have to sign the copyright on the code over to Sun which can be a sticking point with a lot of companies. After all, why should Sun get to sell the code that you paid to have developed? (And Sun does still sell the code, they have a bunch of different licenses for the Java code including commercial ones, not just the GPL). You also have to go to the expense of reviewing the various legal agreements for contributors and going through the patch review process etc. It's not just a simple matter of putting the patch on your blog and it being magically part of the JDK.

It will be really important for the OpenJDK team to work hard to limit these barriers to contribution if they want to attract contributions. I'm certain it's something that they're already thinking about, but how it pans out with the lawyers will be interesting to see.

The other potential benefit that an open source JVM may provide is the ability to port it to other OSs and architectures. People are already suggesting that this will mean OS X will always have up to date Java just by recompiling. Unfortunately, it's just not that simple, you first have to port the JITC to output PPC code instead of x86 which is a huge job, then you have to rewrite the AWT toolkit implementation to work with Quartz. Then you have to write a plugin that works with OS X browsers and deal with all the Cocoa vs Java threading issues. Then you have a working JVM, but still no native L&F, no tie ins to the OS (Apple provide some reasonably simple but very powerful features like being able to put the menubar at the top of the screen and handle dropping files onto the application etc). It's good that it's possible to port, but it won't happen soon and it won't be easy. Judging by the number of Apple laptops here at JavaOne there may just be enough interest to get it done though. BSD is also a likely candidate for a porting project and that should be a lot simpler.

Beyond that, Java developers aren't going to see much difference except possibly that they have to stop making assumptions that if it works with Sun's JRE it will work anywhere. Of course, that's never been true anyway, particularly from a performance perspective, as people who have brought apps over to OS X have found out. It's a huge change for the Java community, but one that only a very, very small subset of the community is going to be affected by.

The session was a lot more fluff than useful stuff and often went for showy graphics instead of actual usability which is a shame. There were some good ideas though.

• Use a modern L&F - they suggested Nimbus. Gosh it's ugly and gray. I suggest using the system native L&F (except on Linux and Solaris then anything is an improvement)
• Add a splash screen, can do this with the -splash argument in Java 6.
  • Supports alpha transparency so can be non-rectangular
  • Should provide a progress bar.
    • They used a sepia image fading into color to show progress which looked cool but didn't really show progress at all effectively.
• Validating Data
  • Give feedback immediately.
  • JGoodies can provide a small icon in the corner of the component. You can do this yourself by painting the icon in the layered pane's popup layer.
• Custom Components
  • You can improve GUIs by creating custom components.
  • This is where they messed up usability in some places. Make sure your custom components are significantly easier to use than the standard components otherwise it's better to go with what the user is used to. Also need to consider accessibility which they didn't mention at all.
• Improve interactivity by updating search results immediately as the user changes values.
• Use cyclic gradients for improved performance, even if you don't need the cyclic property (just paint one iteration).
• Measure text with:
  • g2.getFotnMetrics() then stringWidth and getAscent
• JList has a setLayoutOrientation method which lets you use it as a multicolumn list.
• You can span text across all the cells in a row by clipping the text with a JViewPort to show just the section inside the cell currently being painted.
• You can animate the changes made when sorting by painting the animation in the glass pane over where the table is.

These are my notes from the technical session, "Being Productive With Swing" by Ben Galbraith. The session focussed a lot on Ben's library that he's creating which was a shame but there are some ideas that are worth taking away.

The techniques described below are very specific to business applications that center around forms. At the moment desktop applications are "stepping up the wow" to compete with AJAX and Swing traditionally hasn't had this - JavaFX is likely to bring this to Swing. However, for most business applications "wow" isn't a requirement, productivity is. In that area, no emerging platform provides material advantages over Swing with the exception of JFace and Cocoa.

JFace has some really nice abstractions which make it productive, but is hard to learn.

Cocoa has great data binding via Core Data and excellent tooling support which makes it very productive, but it's Mac only.

For business application development, productivity is king. How quick is it to make, how easy to reuse, how cheap to maintain? Swing's not too far from being productive but isn't there yet. JSR296 (swing application framework) doesn't help with productivity much because it's really just targeted at getting started with an app, not the actual form design. JSR295 Beans Binding is a key improvement.

What's missing from Swing? It needs to be a framework instead of just a GUI toolkit. What's a form? How does validation work etc .

Template Pattern

There are too many ways to create a GUI which makes understanding and reuse difficult. He's created a system to enforce a standard template. The aim is to split the code up and provide as many behavioral contracts as possible to enable reuse. (To me it looks like too much up front engineering - most of the time you don't want to reuse GUIs, they're task specific so what's the point of designing every GUI for reuse?)

GUI Builders

GUIs used to be hand coded because tools weren't good enough. Ben suggests that modern GUI tools have solved that problem and there's no good reason to use a GUI builder and he believes he's vastly more productive using a GUI builder. Often though, people aren't happy about having machine generated code that they then have to maintain. The key is to keep the machine generated code completely separate:

• Bind behaviors to components by name
• Let the builder own all the code it develops
• Supplement the GUI builder at runtime as needed by manually creating just the parts that are dynamic.
• Use an abstract GUI builder plugin system.
  • Support any GUI builder
  • Support custom frameworks.

Ben then went into a particular function he's developed that helps retrieve a component by name easily. Basic idea was taken from prototype.

The issues I see with this that Ben didn't address:

• How do you change GUI builders and preserve the work you've done? What if the GUI builder you currently use is discontinued?
• Ben suggests you can work with a team that uses a range of different GUI builders and it'll still work. Sounds like a nightmare to me.
• What do you do if you don't have access to the GUI builder that was used? How do you maintain the code?

Binding

JSR295 is very exciting. Binding is important to avoid all the code required to copy data between the GUI and the model. This code is often error prone and duplicated, particularly when parsing is required (ints, dates etc)

Opensource binding systems have been available for a while and JSR295 won't be available for some time.

The problem with binding in Java is that most systems try to make the binding bi-directional (automatically respond to changes made in either the GUI or the model). Java doesn't have a way to watch a variable for changes so you have to implement property change notifications which is tedious and error prone. While AOP could be used here, it's not widely accepted and you can't assume that you can just store the current value, make the change and send the notification - some variables need special change handling.

In most apps, there isn't a need for bidirectional binding, it's okay to just provide a method that tells the binding framework when changes have been made to the model (swing already has property change notifications built in so it can use them).

Simple Configuration

It's a pain to apply common attributes like padding, bolding etc to components. Ben implemented CSS for Swing to work around this. To me CSS doesn't apply particularly well to Swing - it's a DSL for styling HTML, not swing. It would be better to create a DSL specifically for styling swing if you wanted to go that route, but if you're using a GUI builder you should just use the GUI builder to do this so that it owns all the code and you can see what it actually looks like in the GUI builder. Otherwise, write the GUI by hand and just use utility functions to set up components with the default settings you need.

Ben's framework is available from http://code.google.com/p/swing-clarity/