Deft Code

PING

I’m now pinging blo.gs and weblogs.com. Other services pinged upon request.

Full entries in XML

I updated my syndication feed so full entries are provided. Enjoy.

Duplicate Class Path Entries

This is my first entry in what I hope will be an ongoing series called ‘Journey to a Solution’. Basically, I’ll document how I fixed a particular problem. Often when I’m reading how a developer fixed an issue, I’m left wondering how they ever fixed the problem; we all have a tendency to leave out all the dead ends and in-retrospect-dumb things we tried that could never have worked.

So on with the show:

The problem

We’re considering upgrading to Java 1.4.2 from 1.4.0 on our production servers. Taking the bold step of trying this out in development first uncovered a weird issue: whenever running code with 1.4.2 (whether via Tomcat or junit tests w/ant) we got these errors:

    [junit] Oct 27, 2003 5:08:49 PM java.util.jar.Attributes read    [junit] WARNING: Duplicate name in Manifest: Class-Path

How I fixed it

• google search: nada.


• Does this mean we have duplicate jars in the classpath? Use ant -verbose test to find out. (Oi, 77 entries. I hate classpath issues.) Nothing obvious, but this doesn’t stop me fiddling fruitlessly with build.xml to no effect.


• What the hell is a manifest file again? Google provides. A manifest file is created whenever you create a JAR file. Hey, maybe we have a Manifest file in one of our JARs with a duplicate Class-Path entry. (It should be obvious at this point why I get paid the big bucks.)


• So we have somewhere around 70 jar files that could have an extra Class-Path line. (I hate classpath issues.)


• We need to: unpack each one, grep for Class-Path, repeat.


• I copy all suspect JARs to a temp dir and start doing this. Eventually I remember that computers are good at automating repetitive tasks (who knew?) and write a quick shell script:

  #!/bin/tcshjar xf $1chmod +x META-INFgrep -i class META-INF/MANIFEST.MFecho "Finished looking at $1"rm $1rm -r META-INF/ls



• Now I can quickly scan a particular jar with quick.sh foo.jar. (Full disclosure aside: this is just the final quick.sh; the chmod line is there because I was initially using unzip -l instead of jar xf and it would sometimes not have execute perms on the dirs. As it is now, I don’t think it’s necessary.)


• Eventually, I find the cuplrit: struts.jar.

Great! Now I’ve identified the problem, I just need to fix it. This involves unpacking struts.jar, fixing the manifest file (instead of multiple Class-Path: lines with one jar per line, one Class-Path line with multiple jars separated by spaces), and repacking the jar ( jar cmf ../MANIFEST.MF struts.jar *). Test runs now have regular output. Joy.

What I’d do differently next time

• Read the error message more carefully. Went a bit down the wrong road because of this.
• I haven’t checked this, but I suspect if I read through the release notes for 1.4.2 (and maybe 1.4.1) I’ll find reference to this change.
• I suspect if I’d stopped and thought a bit, I could have come up with an even cleaner solution to looking through all those jar files; it could even be that there’s a tool out there for doing just that. If I had greater facility with shell scripts, I could also have done it that way.

Update: Did some browsing of sun’s Java forums, which are unfortunately behind a registration wall, and therefore not indexed by search engines. [That this is stupid is fairly evident, so I won’t comment further upon it.] What I learned is:

• The specification is clear that if there is more than one Class-Path entry, only the last will be used. Unfortunately, there is a tutorial somewhere on sun.com that says otherwise. This has resulted in many a bug.
• There is also a 72 byte limit to manifest file lines. You can use SPACE + NEWLINE as a continuation marker (again, this is in the spec.)
• There is a bug (registration required) that documents the change. This bug is still marked as in progress at this time, although the description indicates it’s a 1.4.2 change
• Nothing in 1.4.2’s changes file or README document this change.

on autobuilds and Ant

So everyone pretty much agrees that regular automated builds are a good thing. Seeing as I tend to open my big mouth at work and concur with such sentiments, I’ve talked my way into building a system that will:

• pull the required code from cvs
• attempt to compile said code
• if code compiles, attempt to run unit tests
• calculate various code metrics on the code
• produce an html report of the results, with links to all the details

Now, first some things about the code base in question:

• it’s in java, with a build.xml for each ‘project’ (for us, a project = a web site section or a library)
• each application is consistently laid-out (similiar build targets, directory structure, etc.)

My first stab at this problem resulted in a perl-generated build.xml file that would generate all the necessary targets for a list of applications. (Ant isn’t a programming language - there is no concept of iteration.) This wasn’t good enough for a variety of reasons:

• how do you handle failures?
• if a sub-build fails, it can nuke the entire build.
• how do you only test what compiles?

So, at this point, I did what should have come first, and searched for pre-existing tools that might do the job. What I found was that tools were either a) too limited (can’t run arbitrary build targets), or b) so baroque in their configuration and terse in their documentation as to be useless without a week lost to tweaking.

So I spent the day writing a perl script that will run the autobuild and generate a report on the results. (Aside: it also sends email to the team; I’ve now had to generate mixed/alternative email in both Java and Perl; an instructive experience.) It is, perhaps, not what a Java purist would have done, but I find purity so very tiring when I’ve got work to do.

Good, clean, geeky fun

gDesklets are desktop applets for Gnome. They’re pretty cool; I think there might be a project in here to kick my ass to learn python. The actual utility of many of the displays is questionable, but you know you want to try it.

On Migrating to an IDE

While I’ve toyed with various IDEs over the past year, nothing has convinced me to leave the loving embrace of xemacs. I’ve been a pretty hardcore (x)emacs user for about 4 years, even going so far as to write a movable type mode for it. For a while, I even used it as a mail client.

Programmers tend to become very attached to their computer environments, and an editor is a major part of that environment. Eventually, you accrete so many time saving little tweaks and memorize so many shortcuts that you stop having to think about how to shift chunks of text about the screen, it just happens. As a result, changing how you edit code requires you become less
productive for a period of time.

Now, an IDE is more than just an editor, it basically promises a complete solution to producing code - usually encompassing code generation, code assist, syntax highlighting, on-the-fly compiling, integrated debugging, build management, source control support, refactoring support, and more.

It’s this last item, refactoring support, that brought me to the conclusion that leaving behind xemacs as my primary coding editor is worth it. Being able to rename classes, methods and properties, extract interfaces or superclasses and a dozen other code cleanups allows me to constantly improve me code without worrying about breaking everything in a project.

There a many other nice things as well: instant notification of syntax errors with quick fix, easy addition of import statements, code assist (available in JDE for emacs, but a lot slicker in Eclipse), easy creation and execution of JUnit tests, and on and on.

This said, there are a few things that are still bugging me. One, the emacs keybindings are not complete (this is a problem I’ve came across in testing other IDEs as well). For example, cutting and pasting, one of the most frequent operations I use, is completely hosed. I don’t think there’s a real concept of marking point, so selecting text is a chore when using the keyboard. Two, keyboard macros are a massive time saver in emacs, and don’t appear to be present at all. Three, the CVS integration layers on some eclipse-specific terminology that still throws me a bit. Fourth, there isn’t the massive pool of hacks and customizations floating around that allow you to tweak your editing experience to perfection. (This may be a good thing.)

I’m sure as time passes I’ll get more comfortable with Eclipse and miss these things less and less, or figure out how to go about achieving the same ends using Eclipse.

One final thought: there’s great value for a programmer in being intimately familiar with a language before relying on a tool to automate the boring bits. The boring bits are important, and if you’re not aware of what’s going on in your code, you’re pretty much guaranteed to have your ass bitten by something you don’t understand, and your boss or customer isn’t much going to care that your IDE did it.

Readers!

Wow, the difference a post can make. Traffic is a magnitude higher over yesterday; I suppose I’ll have to get let my sarcasm out to play more often. Thanks Simon!

jvmstat

A good reason to upgrade to Java 1.4.2: jvmstat.

The jvmstat technology adds light weight performance and configuration instrumentation to the HotSpot JVM and provides a set of monitoring APIs and tools for monitoring the performance of the HotSpot JVM in production environments. The instrumentation is designed such that it is ‘always on’, yet has negligible performance impact.

Found here, which also claims that 1.4.2 is much faster on Solaris and Linux.

Java Dates

The perversity of Java’s date handling is well known, but here’s today little bit of nonsense:

Calendar.getInstance().getTime() returns a Date object representing the current time.
date.getTime() returns the time represented by the Date object date in milliseconds as a long.

This means it’s possible to get the current time in milliseconds with Calendar.getInstance().getTime().getTime().

You’d never do this of course, there being getTimeInMillis() available on Calendar, but it helps explain why I have to go to the API every single time I deal with dates in Java.

Java's floating point

Something I didn’t know: Java’s floating point arithmetic sucks:

Java’s floating-point arithmetic is blighted by five gratuitous mistakes:

1. Linguistically legislated exact reproducibility is at best mere wishful thinking.


2. Of two traditional policies for mixed precision evaluation, Java chose the worse.


3. Infinities and NaNs unleashed without the protection of floating-point traps and flags mandated by IEEE Standards 754/854 belie Java s claim to robustness.


4. Every programmer s prospects for success are diminished by Java’s refusal to grant access to capabilities built into over 95% of today’s floating-point hardware.


5. Java has rejected even mildly disciplined infix operator overloading, without which extensions to arithmetic with everyday mathematical types like complex numbers, intervals, matrices, geometrical objects and arbitrarily high precision become extremely inconvenient.

To leave these mistakes uncorrected would be a tragic sixth mistake.

Update from comments: One of the authors of this paper now works for Sun; his take on things is now a little kinder to Java.

XPath

I’d heard of XPath, but never really understood the fuss. Now I do.

Empower ISV

I gotta agree with Joel: Microsoft’s Empower ISV package is a ridiculously good deal. If I were an MS Developer, I’d be all over it.

Ant 1.6 Beta

Ant 1.6 Beta has escaped. Get it here. Nothing hugely exciting from my perspective, with the possible exception of the new <scp> task.

On Text

Attention programmers: Text is hard.

But only if you want to do it right.

Eclipse 3.0M4

Get it while it’s hot: Eclipse 3.0M4. What’s new.