Pain and Glory from the Trenches of the IT World

A short while back I wrote about how Scala’s interoperability with Java is not necessarily a good thing. One of my main suggestions was the avoidance of Java-based class libraries. Although they may fit well with the Java way of doing things, they likely won’t be a good fit when it comes to making the best use possible of the language features that Scala offers.

Furthermore, I suggested against the wrapping of existing Java classes to produce more Scala-friendly classes. Interestingly enough, one of the responses to that article puts a lot of focus on this point: The argument for not using java libraries directly is perfectly fine: their interface sucks for Scheme developer, but the argument against writing wrappers around them appears to be a feeling rather, not a thought-through statement: “use of such adaptor code often leads to messy software”. Eeee, no? It doesn’t? Take a look at swing. It’s a widget toolkit that was first implemented in java as a wrapper around awt (the older and miserable-looking GUI lib). With time it came into java’s standard library and in jvm version 1.6 was completely rewritten in order to make it more effiicient. Isn’t it the best way of implementing libraires for Scala?

First of all, Swing is still implemented over AWT. This rewrite that is spoken of didn’t happen. There was improved graphics acceleration on Windows, and improvements to the Windows and GTK+ look and feels as part of Java 6. But Swing was not “completely rewritten”. Due to the level of integration between Swing and AWT, it’s quite doubtful that a full rewrite would ever take place. And if Swing were to ever be completely rewritten, I would hope that the result would actually not look much like Swing at all. Making the same mistakes over and over just isn’t sensible.

Since Swing is just layered on top of AWT, one would think it’d be easy to use both in the same application. Wrong. This article shows just some of the problems when mixing Swing and AWT. There are z-ordering issues with some overlapping widgets, AWT components can’t be placed inside JScrollPane components properly, and so forth.

Then we can look to the JFrame class. It’s the Swing class representing a framed window, and inherits directly from the AWT Frame class. One source of API messiness arises with Frame’s getMenuBar() and setMenuBar() methods. The equivalents for the JFrame class are getJMenuBar() and setJMenuBar(). That’s just ugly.

Futhermore, notice that Swing’s JMenuBar class is only related to the AWT MenuBar in that they both inherit from Object if you go back high enough in their inheritance hierarchies. So what we end up with is a messy, convoluted API due to the wrapping of existing code.

So as we can see, Swing is a perfect example of software quality taking a nosedive due to an attempt to reuse poor existing code. I hope people in the Scala community take note of such past mistakes. They’ve got a perfect opportunity to create a language and environment that is free of many of the problems of Java. Avoiding existing code that just won’t mesh well with the language features of Scala is a great place to start.

This entry was posted on Saturday, August 25th, 2007 at 2:15 pm and is filed under Development, Java, Software, Windows. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.