Where is the Pain?

• GUI creation and maintenance
• Threading issues
• Widget <-> model binding (n-tier application)
• Input validation

Reaching Nirvana

• All about frameworks -- buying, building, or using them
• OSS frameworks are ideal (great to have source code)
• building should be last resort

No uber framework

• Ideally, one framework would solve problem
• doesn't exist
• Two wannabees: NetBeans platform and Spring Rich Client Platform (RCP)
• Vibrant space (new projects popping up all the time)

NetBeans

• Doesn't address pain points for big apps
• lack of documentation (yeah, I agree)

Spring RCP

• Inspired by Eclipse RCP and JGoodies
• Not released yet, lot of code in CVS
• not ready yet, but keep an eye on it

No comprehensive framework, some smaller focused ones

• JGoodies Swing suite ($$$) - has been released, some free parts
• SwingLabs - Sun's OSS collection of helper frameworks. Also not out yet.

Solving the Pain

• DRY - don't repeat yourself. Do something twice --> build framework
• Think Ruby-on-Rails (interesting web framework)
• Ruby-on-Rails was built this way, so it was a framework that was built in an interactive manner, only for functionality that was actually needed.

Reuse hard in Swing apps, because no strong conventions, GUI layout code can be everywhere.

Solutions

• GUI builders, but with restrictions
• Use GUI builder to generate binary artifact (like XUL), user-modifiable code sits outside
• Load generated GUI at runtime, and manipulate it
• Provide standard contract for screen creation
• Introduce form abstraction (smaller than screen, larger than a widget)
• Both practices increase opportunities for reuse

Framework examples

• JFace has Window and ApplicationWindow classes
• Spring RCP defines Page and View abstraction that aligns nicely with Screen/Form concept

Threading Issues

• Swing components are not thread safe -- only supposed to be accessed by AWT event thread.
• SwingWorker (new in Java 6, being back-ported to Java 5) and Foxtrot?
• Comega - experimental programming language from MS, used as a sandbox
• Concurrency is hard -- Servlet API is admired, because it is simple and single threaded, yet it scales up
• Because there is a container that does heavy-lifting of thread issues
• Container-managed Swing (Inversion of Control)
  • Have container control object, and provide services for object
  • Load and initialize screens on background thread
  • Handle asynchronous population and action execution

Tools

• JFormDesigner - excellent GUI builder tool
• Matisse - next version of NetBeans
• FormLayout - 3rd party layout manager that kicks GridBagLayout in the you-know-where
• IntelliJ IDEA - IDE

Summary: This was a pretty good talk. The take-aways are to go and keep tabs on some of these frameworks (they may need another year), and to look into some GUI builders and 3rd party layout managers.