JRuby cannot save Swing.
Over the years I’ve done more work that I’d care to using Swing, the main GUI framework included with Java these days. But myself and other developers I know have become disenchanted with it, for a number of reasons. So I became quite interested when I read an article suggesting that JRuby could help save Swing. But after reading the article, I have come to the conclusion that Ruby will not be able to save Swing.
The very soul of Swing is flawed, and that’s where the major problems arise. The first problem many development teams run into when using Swing is the fact that it’s rather slow. While I have not performed any profiling of it, I would suspect that the extensive layering of Swing over AWT, the JVM, and so forth may contribute to the performance problems. Furthermore, the fact that much of the rendering is done in Java is likely another performance sore spot.
The second major problem is cruft. As Swing has evolved, old functionality has been retained for the sake of backwards compatibility. This builds up, making the API unclear and at times confusing for developers today. The reliance on some AWT classes for certain functionality also can cause confusion. The uncertainty that arises about which methods and classes to use can harm developer productivity. Instead of writing code, these developers are stuck wading through page after page of JavaDoc documentation, trying to find which API to use.
There are other problems with Swing, and the article does mention some of them. A number of those problems derive from the above to core issues. For example, the poor reputation of Swing applications is usually due to the poor performance. The difficulties when it comes to layout managers and maintaining Swing applications arise because of the reuse of AWT code and the cruft of backwards compatibility.
The article suggests that Ruby, via JRuby, will help the situation. The article also suggests the use of an XML-based GUI representation, and a simpler API layered on top of Swing. Such things will only add to the complexity that Swing developers currently need to deal with. One of the main problems with Swing are all the layers: adding more will just make the situation far worse!
There comes a time we need to start over anew, instead of trying to repair what we have. That is where we are at with Swing. It has outlived its usefulness, and should be thrown out. Ruby will not save it. A complete redesign and reimplementation is our only choice.
February 22nd, 2007 at 9:07 pm
[…] I recently wrote an article entitled ‘JRuby cannot save Swing’. Well, Danno Ferrin has written a rebuttal of sorts that I’d like to address. […]