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 :)

6 comments:

Robert Ancell said...

I should add that while GTK+ works well for me, the documentation is completely lacking. The behaviour of the signals need to be defined properly!

Anonymous said...

Have you tried the UI builder in Netbeans? It's just so far beyond glade.
http://testwww.netbeans.org/kb/articles/account-with-matisse.html
http:/
/www.netbeans.org/kb/articles/matisse.html

Robert Ancell said...

Q. Does the window only shrink to a minimum size? If so why does it do this here and not in vanilla Swing? Does the UI builder build code or an interface file?

GTK+ does support some of these concepts using gtkSizeGroups but certainly not with Glade. The text alignment was quite nice - I wonder how that holds between different themes?

GTK+ doesn't normally use absolute layout (I think you can do it though) which annoys people who want things just-so - I quite like the "logical" layout so the GUI can handle themes (and your layout is simpler).

Perhaps AWT and Swing should be deprecated...

Anonymous said...

Threading is NOT an optimization. Threading does not increase performance.It is just a paradigm for managing things that must happen concurrently and scales MUCH better than polling.

Robert Ancell said...

I never said anything about polling. A single blocking loop will solve 99% of you problems without any chance of race conditions.

Any heavy processing based on the input received can then be farmed out to a thread as an optimisation.

Good to see I've got you attention Mr Smith :)

Anonymous said...

Could be any Java fanboy named Shannon.
Also, the Java standard library kicks the crap out of any I have used (logical names + excellent docs).

I find the GTK API is ugly/hard to read (which I think is very important), Qt is reasonably nice, SWT is Ok and I like AWT/Swing best.