Alex's Adventures on the Infobahn - java

Thoughts on Java

2010-02-12T11:18:00+00:00

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 (tm). 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.

Context, Attributes and JSP

2008-07-10T20:02:00+01:00

One thing that is rapidly becoming clear is a lot of different concepts get mixed together when you start playing with JSP. On the face of it it's a simple model, your JSP code get built into a Java class (of type servlet) which is a combination on normal Java code and JSP mark up which gets converted into Java when the page is loaded. At any point in your HTML you can escape back into Java code, do calculations, execute loops, generally compute things. However that approach can get very messy because you end up spreading logic all through your presentational HTML. This is why using an MVC pattern is so encouraged. Put all your logic and complex code at the top of the file and then display page expanding the odd attribute here and there.

However I don't think I've fully grasped whats going on behind the scenes. It doesn't help with Jetty I can't find where the intermediate Java source code is generated. Trying to understand whats going on when I'm not familiar with the cryptic backtraces has been frustrating to say the least.

Now I'm a little confused as to what exactly happens with the ${var} notation in terms of the java code generated. My earlier code has mutated to a list with a custom class. Hence I have had to generate the following:

<c:forEach var="entry" items="${model.jvmMemInfo}" varStatus="status"> <% // This is complex, I'm not sure how you can use ${} syntax on // arbitrary objects to expose the values, hence this bit // of inline java. I'm open to elucidation on how you would do so NameValuePair data = (NameValuePair) pageContext.getAttribute("entry"); %> <tr> <td> <%= data.name %> </td> <td> <%= data.value %> </td> </tr> </c:forEach>

However there are examples on the net showing arbitrary classes exposing their contents with this simple ${data.name} type syntax. I just couldn't get it to work. My NameValuePair class isn't much different from their one. I suspect this would be a lot easier to work out if I could see the generated applet.

Any Java web monkeys got experience with Jetty or can tell me what piece of obviousness I have missed?

JSP tags

2008-07-08T14:56:00+01:00

Arrggh. I've just wasted the best part of half a day scratching my head as to why I was unable to iterate through a Java HashMap in a JSP page:

<c:forEach var="entry" items="${model.jvmInfo}" varStatus="status"> <tr> <td> ${entry.key} </td> <td> ${entry.value} </td> </tr> </c:forEach>

It would of been immediately clear had I looked at the resulting HTML the page was echoing. Note to self, always check you have explicitly included the taglib you are planning to use.

Too much perl, the irony

2008-06-24T16:42:00+01:00

I got my current job based on my experience with C/C++ and GTK. So far most of the code I've been writing has been perl and Java. Some times I think I'm writing too much perl:

# Quick and dirty match for IP (but without the tedious address # verification) my $ip_match=qr#([\d]{1,3}\.[\d]{1,3}\.[\d]{1,3}\.[\d]{1,3})#i;

The tedious address verification is what I laboured through on one of my Google phone interviews. I'm still not convinced by the argument of doing within the regex, and it will make it the regex so much more ugly and hard to follow. I skipped it here because the data is already verified and all I really need to differentiate from is [d]*.

Open Source Ripping

2005-09-01T12:27:00+01:00

So it came to pass I was chatting to Andy last night and I noticed he was typing the CD sleeve details for the CD being ripped. I was surprised as thanks to the magic of FreeDB every CD I've ripped in the last few years has automagically had its details filled in and tagged^*. So cue a quick look around the application Andy was using to find the settings for the CD lookup and see if we can set it to use the freedb database. Unfortunately the CD lookup option was a tick box (do, or do not, there is no alternative). Whatever the application did it was hidden from us.

Now of course I could have just suggested Andy run Linux where there are a range of rippers^** ready to run. Experience has taught me people don't want to change OSes, no matter how much I point out the benefits of open systems. However more and more FOSS software is available for the Windows platform so a quick search of freshmeat pointed us at jRipper.

The installation^*** didn't go too well. First we needed the latest Java before we could proceed and then when actually running the app showed its rough edges by screwing up some of the shortcuts and not making it very clear how to configure the ripping drive. This is understandable as it is basically tuned to running on Linux. However it doesn't give a good impression to people running it on other systems. Luckily having experience with the tools I was able to eek out the settings Andy needed and we set it off ripping. Time will tell, now the app is set up, if Andy will find his new FOSS application superior to the commercial competition.

*Occasionally I use the excellent EasyTag to mass clean up tags. Its pattern matching abilities make re-tagging track names that are Track/Artist on compilation albums a breeze.
**For the record I use Grip to rip tracks into 160kbs Oggs.
***Since I'm used to packaged apps I find the concept of individual installers, each with their own little foibles and idiosyncrasies rather archaic. On all my systems installing a package is generally a single command line which automagically pulls in required dependencies as needed. As the software is all installed via the package management system un-installation isn't the gamble I recall from my Windows days. And don't get me started on how easy it is to audit every executable on my system and know where it came from.