Friday, March 30, 2007

Working with Java

Or should that be Working against Java...

I've more-or-less come to the end of a project refactoring a large Java GUI application for my company and I now feel I can justifiably have a practical opinion on Java. This was my first commercial work with Java and I'll compare it to C/Python/GTK+ which I have used both commercially and in open-source projects.

Java is far more complicated than it should be. Count the number of methods each class has when browsing the documentation. The complexity of the standard library exceeds the complexity of the problems you solve with it. Compare it to the Python or even C library. Instead of containing the basic tools and tools that you use frequently it's full of cruft. I think the programmer should either build up more complex functions themselves or use higher level functions from a different namespace (compare GL and GLU libraries in OpenGL).

AWT and Swing are just a complete mess. Sure this is for historical reasons but Java needs a serious replacement. Maybe SWT is it but if some leadership is not taken to make a "standard" GUI that works I cannot see vanilla Java surviving compared to something like .NET. Case in point, java.awt.Component has four variations on getting keyboard focus. And reading the documentation on each is just worring... You may not get focus, you should use the requestFocusInWindow() because it is more cross-platform. I used to work with a commercial Java developer and he described the cross-platform support as write once; test n times. I now understand.

Packing in AWT/Swing is just too difficult. The simple packing models are too simple for most cases and the complex ones create too much code. While the GTK+ model is more complex to start with I'm always surprised how my windows "just work" (try shrinking a Java window and see everything get messed up). Java needs a universally accepted equivalent of Glade or XAML.

Connecting signals takes too much code. Using Listeners requires you to write loads of empty methods to catch signals you want to and Adapters can't be inherited if you're already extending another class. I hate inline classes with a passion (so much code for so little behaviour!). Using SwingUtilities.invokeLater() (which is a really practical method that should be more central to Java) to create a runnable class every time you want to access one method later? Overkill. Why not just gobject.idle_add(method)?

Threading... All I can say is threading is an optimisation. I've seen too much excessively threaded code that is very hard to maintain. Java seems to implicitly encourage you to thread which I do not like. I don't like that a lot of the Graphics operations don't seem to have an easy way of doing them synchronously. Threading is an optimisation.

Really it's the library that lets Java down. The language is a huge improvement over C. It lacks a little in low level access (I have not really done this in Java but from a first glance it may be missing something like Pythons struct module). I dislike the lack of flexibility over Java but I do like the compile time checking for catching bugs. I must try a .NET project to see if .NET doesn't have the baggage Java does. I get the impression the dominant members of the Java community have the opinion "Don't change anything, we've got too much code" as opposed to "Keep version X stable as we have lots of code, but make version X+1 fix the big problems in X".

My opinion of Java? Not ready for the enterprise :)
Post a Comment