Will dynamic languages save Swing? Does Swing need saving? These questions have been discussed in detail over the last few days with opinions varying from JRuby to Groovy as saving Swing to Swing not needing saving.
Julian Doherty started the discussion by stating that JRuby can save Swing. Building on 2003 post by Joshua Marinacci that listed the following reasons for Swing’s failure:
- Swing apps are slow to build.
- Swing layout managers suck.
- Swing apps are hard to maintain.
- Swing is too powerful.
- No native features.
- Swing apps have a bad history.
Doherty points out how dynamic languages, and Ruby in particular, can help resolve these issues. Responding to Doherty, pinderkent states that Swing is beyond saving due to performance and the build up of APIs that are not consistent with the evolution of the language.
Danno Ferrin jumps in rebutting some of pinderkent’s arguments and stating that Groovy is a good candidate to save Swing. He points out that Groovy’s closures will help developers avoid expensive computations on the Event Dispatch Thread. pinderkent maintains that Swing’s APIs make it unfixable.
Finally, Daniel argues that Swing doesn’t need saving. He goes back to Marinacci’s six points and disputes all of them. The discussion on his post goes on to debate the advantages of Groovy’s SwingBuilder (and similar libraries in JRuby) in speeding Swing development.