Suggestions for Swing

David Shay's weblog Scratch Where It's Itching says that there is an opportunity to have input to the requirements of the next version of Swing. He has sent them 9 or so suggestions (to editor AT javadesktop DOT org).

Here are mine:

• Homogenise the Document/Model usage. Some components have models that must be extracted, some components can be supplied with models. It would be nice to be able to supply a Document or strongly typed model to each component uniformly.


• JLabel should have a model to support push based displays.


• Take out the programatic manipulation of individual component properties (e.g. setForeground). I consider these to be the UI equivalent of gotos as they make the UI unmaintainable. Replace them with a mixture of PLaF and rendering hints. But for this to work it must be easier to create a custom LaF (e.g. properties, XML).


• Flatten the component type hierarchy by adding more atomic interfaces. This makes it easier to write common UI components and share code between Swing and web UIs.


• Use one of the many IoC techniques to make it easier to drop components into containers. The linkage would not need to be that complex as you might have a hierarchy of containers that you drop named Actions, Listeners and UI components into. This would have the added benefit of creating scope for lifecycle based functionality - i.e. fewer repaints.


• Hide the Swing thread totally. Is there ever an instance where you want the whole UI blocked? Use a thread pool and synchronize on the glass panes for concurrent repaints. Event handlers can then safely execute explicit non-UI operations.


• Use component factories to reduce the gc load in active UIs by recycling.