Pinderkent

I recently wrote about how undetected type errors when using languages like Ruby and Python can be quite dangerous. That article has gotten some notice, with one response considering Groovy.

The article about Groovy purports to have an example of a statically typed Groovy script that compiles fine, but results in a type error at runtime. The script is:

int x = "test"

The error received at runtime is:

Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot
cast object 'test' with class 'java.lang.String' to class 'java.lang.Integer'
at typesafe.run(typesafe.groovy:1)
at typesafe.main(typesafe.groovy)

If Groovy were truly a statically typed language, then the compiler would have raised a compile-time error. But since that did not happen, one or more of the following may be true:

1. The Groovy compiler does not perform adequate compile-time typechecking.
3. The Groovy compiler performs compile-time typechecking, but a bug prevents it from catching this particular error.
4. The semantics of Groovy prevent it from being a statically typed language.

The essence of static typing is that such an error would always be caught at compile time. We can't say that a language is statically typed if such an error occurs at runtime. Just because the programmer can specify the type of a variable (eg. 'int' in this case), it does not mean that the language is statically typed. This is especially true if the compiler or interpreter completely ignores such type specifiers at compile-time.

So in this case, I think the verdict is quite clear: Groovy cannot be considered a statically typed language, as it exhibited a runtime type-related error.

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.

He does bring up a good point about performing heavy operations in the event dispatch thread. Such things can become a real problem, in terms of the application's performance and responsiveness. However, I'm not convinced that such developer mistakes are the only problem.

I do think Swing is slower when it comes to rendering, for instance. Even small applications that do minimal processing tend to have a certain lag to them, especially when compared to similar applications written using a toolkit like GTK+, Qt, MFC, Cocoa or even SWT. Someday I'd like to perform some profiling and benchmarks, as best as would be possible, to get some numerical data to work with.

Yes, I know people will tell me that Swing is more responsive in Java 6, and that OpenGL can be used to accelerate the rendering. But those aren't solutions for all people, especially not for many businesses. There are a fair number of corporate users who are still hesitant about moving their client-side Java applications to Java 5, for various reasons. Moving to Java 6 may be out of the question. Furthermore, the PCs used in many corporate networks have minimal graphics hardware, thus reducing the benefit of OpenGL. And if they're using a system like Linux, there's a good chance that the only OpenGL support they have may be software-based, rather than hardware-based. I wouldn't be at all surprised if such software rendering would make things even slower.

Now the part of the rebuttal I would most like to discuss regards the Swing API. I think we need to distinguish between it being "difficult", and "convoluted". The Swing API itself is not overly difficult to use. The concepts are pretty straightfoward, and most developers can cope with them easily. It's more a matter of the API being crufty, which makes it awkward to work with.

An example of this is how integer constants are often used in Swing where enumerations would be best. Of course, the inclusion of enumerations later found in Java 5 wasn't known about when many parts of Swing were initially developed. And maintaining compatibility with existing code prevents or limits such APIs from being changed now and in the future. It is thus rather annoying to have to resort to type-unsafe integer constants when enumerations often provide exactly the facilities that are needed.

Another example, which I mentioned in my earlier article, was that of the layering of Swing over AWT. The layering itself is not necessarily a problem. What is a problem is the mixing of the layers. The layout managers are a good example of this. You can use java.awt.BorderLayout, but you can also use javax.swing.SpringLayout. Again, I understand the reasons for such things not being changed. But it is a sign of cruft when you have to look in two separate packages for classes that perform the same type of function, especially a pretty important and frequently-used function like that of GUI component layout.

It makes sense to reuse code wherever possible. But it should be done in a way that doesn't lead to the accumulation of cruft. The consistency problems mentioned above probably can't be dealt with unless a new toolkit is started, learning from the mistakes and experience of AWT and Swing. Some people may say that that has already happened with Eclipse, SWT, and the accompanying frameworks.

We only need to look to Qt to see a GUI toolkit done right. Several years back I was involved with a C++ project that used Qt, and it's a remarkable toolkit. It's fast, cross-platform, and well-implemented. The API is extremely well designed and consistent. And the layering is done quite well. The toolkit is developed in such a way that it makes use of underlying APIs and layers, but it doesn't expose them to the developer unless absolutely necessary. It's a pleasure to develop with, and the resulting applications are enjoyable to use. While I haven't used it myself, perhaps Qt Jambi does a good job of bringing this experience to the Java world.

I can't really speak much about how Groovy could improve the Swing situation, as my experience with Groovy is quite limited. But as I've stated several times now, I don't think the problems with Swing can be fixed by using another language like JRuby or Groovy, or by adding additional layers, and so forth. More drastic action is needed.