Isn't it time for GCJ to die?

What's the motivation for gcj these days?  Originally, everyone wanted a GPLd JVM so gcj kinda made sense.  At least in spirit.  It's never been a functional equivalent for an actual JVM, though.  I've seen nothing but problems with it for years in IRC channels.  It's partial implementation of the spec has led to endless confusion for uncounted newbies coming to the java channel for help.  It doesn't help that the ideologues at Debian, et. al, continue to package gcj as if it were java.  Well, we have a  GPLd JVM now.  Everything about it is open source (or just about done...). GCJ, as I see it, serves no more useful purpose than allowing those in charge of it to hold on to some ideal (or maybe pride).  I know this is inflammatory for a good number of people, but why persist?  Is it the native compilation you like?  The slow, misbegotten catastrophe that it is?  It's slower than running java bytecode and seems to eliminate several key features of Java (like dynamic classloading).  Even before Sun GPLd their (our?  I'm a Sun guy after all...) JVM, gcj adoption was miniscule at best.  So, what's the point?  Can't we move on from gcj?  Or at a minimum, stop packaging it as the default JVM when it's not actually a java implementation?  That'd work for me.  I'm just tired of seeing newbies getting tripped up by some distro's ideological navel gazing.

Changing the Current Directory

One of the more common requests I see online from beginners (and from a not-so-beginner just now) is how to change the current directory.  This one is really simple, so here's a quick snippet and the output.

System.out.println(new File(".").getAbsolutePath()); System.setProperty("user.dir", System.getProperty("java.io.tmpdir")); System.out.println(new File(".").getAbsolutePath());

And the output:

/Users/jlee/. /tmp/.

See?  Simple.

String Concatenation Options

There's a new inspection in IDEA 8 (might just be in the EAP at this point) that will convert string concatentation to a variety of different approaches.  One of these options is to use String.format().  I started applying this option to some code I'm working because it's certainly more readable than some of the concatenation stuff I'd been doing.  But I started thinking that I should probably profile this before I get too crazy with it just to make sure I'm not hamstringing myself with this.  So I wrote a simple test to see what the fastest option was and I was a little surprised by the results. First, let's see the code.

import java.text.*;

public class test {
	private static long concat(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = "Loop " + x + " of " + count + " iterations.";
		}
		return System.currentTimeMillis() - start;
	}

	private static long format(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = String.format("Loop %s of %s iterations.", x, count);
		}
		return System.currentTimeMillis() - start;
	}

	private static long format2(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = MessageFormat.format("Loop {0} of {1} iterations." , x, count);
		}
		return System.currentTimeMillis() - start;
	}

	private static long append(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = new StringBuilder("Loop ")
				.append(x)
				.append(" of ")
				.append(count)
				.append("iterations.")
				.toString();
		}
		return System.currentTimeMillis() - start;
	}

	public static void main(String[] args) {
		int count = 1000000;

		for(int x = 0; x < 10; x++) {
			System.out.println("concat = " + concat(count));
			System.out.println("String.format = " + format(count));
			System.out.println("MessageFormat.format = " + format2(count));
			System.out.println("append = " + append(count));
			System.out.println();
		}
	}
}

This admittedly naive "benchmark" runs through four options and prints out the basic timing results.  I've compiled the results below in a table:

concat String.format MessageFormat.format append
408 3164 9099 376
338 2876 8559 340
300 3013 8655 398
342 2938 8511 311
308 2911 8570 310
306 2924 8726 320
316 3019 9006 414
306 2994 8673 331
346 3022 9588 311
312 2988 8590 313

As you can see both format methods take considerably more time than the other two.  I was a little surprised to see this though the magnitude of the difference was more surprising than than the difference itself.  So neither of those are options you'll want to consider in areas that get called often.  The one that was really suprising for me was the relative similarity between concatenating strings and appending using StringBuilder.  While StringBuilder was generally faster than string concats, the difference was rather minimal and in some runs actually slower.  What this says to me is that the generally accepted "wisdom" that String concatenation is slower than using StringBuilder is clearly wrong.

On the other, I'm not really a performance expert so I might be doing something stupid here or missing something fundamental.  The test seems rather straightforward, though.  What do you think?