Thoughts on Java

I’ve been spending the last week hacking around in Java. One of the components of the product I develop is the open source OpenNMS. As I’ve mentioned before it’s been lightly modified by myself to blend in better with our code mainly in the JSP department for it’s web interface. Last week I discovered I needed to make a slightly deeper change to the code to export some more data to it’s scripting interface.

While I was exploring the code base and scratching my head at some of the exceptions being thrown I thought I’d have yet another go at making my Java development environment a little more integrated than binding the build script to “C-c c”.

So far I have a couple of observations about Java code. The first is that it never seems to do very much. As you navigate the code base you tend to find a lot of simple skeleton classes, usually working as simple adaptors between one framework and the next. Thanks to Java’s strong support for generics and interfaces you often find yourself looking at a class wondering what else it might do. None of this is helped by Java’s standard/deep/directory/naming/strategy/of/doom. My usual tools of a decent programmers editor and grep start to show their limitations. Java is a language that is designed to be serviced by a full IDE to help you make sense of the whole system.

Having previously tried and failed to get JDEE working I thought I would capitulate and try Eclipse. I blithely thought that given the fact it’s the standard Java developers tool with a long development history it would Just Work ™. I was to be sorely disappointed.

I tried several different versions on both my home Gentoo machine as well as various PPA based versions on my work Ubuntu setup. A lot of times it failed to start up due to some Mozilla dependency issues and when I did finally get it started I couldn’t get any of the plugins to install. The entire Eclipse stack is designed around the concept of plugins and it seems every Java framework comes with it’s own additional plugin for Eclipse. Without the plugins I wasn’t able to get a working build or any sort of source level debugging. Eventually I had to concede defeat and bin the IDE approach and return to some tedious grep work and piece together the structure of the software by hand so I could finally crank out what in the end was a fairly simple patch. I doubt I shall return to Eclipse.

I did have a brief tinker with JDEE which at least installed better from it’s SVN repo (needing a one line patch). However the documentation is a little sparse on how to import an existing large project into it’s view of the world. Annoyingly potentially useful links like the FAQ referenced on the main site lead to dead ends. I never got to the point of seeing if I had a working Java GUD integration. I hope to revisit JDEE in the future when I’m a little less pressed for time at work. It’s hard to work up the enthusiasm for plumbing in support for a language you never intend to use for fun in your own time.


    • Sadly the last thing I tried was the binary package. Even then I couldn’t actually get OpenNMS to build in it for some unknown reason probably because some of the plugins were not installed properly.

      I agree the distros seem to have issues with packaging Java apps, most likely because Java hasn’t been “free” for that long.

  1. I started using ack mainly because of Java’s deep nesting. It has lots of nice features for other languages too.

  2. That strange, binary distribution of the Eclipse worked fine on my Ubuntu box when I did Java.
    The only issue I run into was caused by GNU JVM which was installed on the system by default. It causes a lot of crashes.
    To fix that, I just downloaded Sun JVM and put it under /your/path/to/eclipse/jre.
    Hope that will help.

    • I suspect these are all symptoms of the relatively immature state of Java on Linux. My work box is running the fairly old Hardy Heron (as that’s what the product is based on) albeit with a fair amount of PPA’s for newer tools (like Emacs ;-).

      We are also stuck with OpenJDK as that is the safest from a distribution point of view.

      The breakages I’m seeing are probably a combination of old base OS and early OpenJDK.

Comments are closed.