Philip Milne, Brendon McLean and Dan van Enckevort.
(Bob is a place-holder name, we’re waiting for inspiration.)
For the last five years or so the GUI builders offered in all of Java’s IDEs have been their weakest aspect. Most professional developers have chosen not to use them, instead resorting to writing Java/Swing code by hand – an extraordinary turnaround for an industry that had been using productivity-enhancing tools for user interfaces since the mid-eighties.
Some cite the difficulties associated with code generation as the downfall of the Java GUI builders. The “back-parsing” problem: reading in the Java code from a saved project and reconstructing the design has been one of the areas that has presented the most of the difficulties. It is perhaps easy to say with hindsight, but trying to solve this problem should never really have been attempted – as solving it has been known for many years to be theoretically impossible. [A corollary of the Halting Problem is that it is not possible to write a program that will look at other programs and to know what they will do in all cases. When it comes to GUI code – the only practical strategy that works for all input programs is to run them and see what happens].
Few things are as frustrating for Mathematicians as when engineers, who have no knowledge or interest in the theoretical foundations of their art, come up with perfectly functional solutions to provably unsolvable problems – typically by finding a short-cut that works in enough common cases to get the job done. Engineers often cite the car as just such an example - in that triumphant way of theirs.
Luckily, this hasn’t yet happened with Java GUI builders and, as of 2003; six years after the first versions of Swing were released, there is still no code-generator that produces code that developers don’t feel compelled to rewrite and no “back-parser” that can reliably infer a user interface from code that a developer has been allowed to edit freely. [Most tools have taken the approach of introducing knowledge of the limitations of their parsing infrastructure into their code editor – forbidding the developer from making certain changes. While laudably pragmatic, these draconian measures do not seem to have solved the reliability problems in any of the commercial tools and, with no standard amongst the tools for what constitutes “acceptable” UI code, projects have, at best, been left tied to the tools with which they were created.]
This builder takes a completely different approach - using “resource files” instead of Java source code to save designs. This technique is neither new (just the opposite) nor due to the authors of this project. It was used in InterfaceBuilder: a much-loved GUI Builder released by NeXT over ten years ago - now part of Apple’s OS-X. Some of the other ideas both in this builder and some of the new classes in SDK 1.4 were inspired by the ground breaking work of the engineers at NeXT. Their contribution is acknowledged with gratitude.
The resource files generated by Bob use an XML encoding and are read by the standard java.beans.XMLDecoder class that was included in SDK 1.4. Because this class was included in SDK 1.4 this builder does not require a “run-time” to support the reading or running of the resource files: applications produced with it will run on a standard 1.4 Java VM.
Bob does not generate inner classes for handling events from the user interface. Instead, events are handled using the java.beans.EventHander class (also new in SDK 1.4) which can be used to synthesize a listener for an interface at run time. Using this technique it is possible (and desirable) to remove all swing and awt imports from classes that implement the application logic – exposing all behavior in terms of conventional (non-GUI) APIs. The set/get pattern of the Java beans specification can be used to expose properties of the application layer for manipulation in the builder. Typically the types of these properties are fundamental types – Booleans, integers, strings etc. and the mapping to and from the internals of the swing components that are used to manipulate them is all taken care of by the EventHander. Just as the application layer can respond to events in the user interface, the UI may respond to changes in the application layer - by registering PropertyChangeListeners on the relevant properties. To make use of this feature, application logic classes must conform to the beans conventions – maintaining a list of PropertyChangeListeners and notifying those listeners when a setter method is invoked on a bound property. It is straightforward to implement listener support from scratch; alternatively it can be delegated to an instance of java.beans.PropertyChangeSupport.
The two main advantages of this separation are to be found in the testing of the resulting application and its independence from the underlying toolkit. Because the application layer now looks like a conventional library or server-side component - with a formal API - it is possible to write conventional unit tests to ensure that it continues to fulfill its contract as its implementation evolves. Additionally, because the swing classes are not normally imported by classes implementing the application logic, it is possible to create another front-end, possibly even with a different toolkit, without making changes to the code comprising the application logic.
Back to top.