'Twas brillig, and the slithy toves did gyre and gimble in the wabe

Ah, I see Oracle have been following the Firefox model of "the more big scary prompts we show, the less likely it is that someone will actually click Run".

Bonus extra post, to avoid talismancer mocking the lack of content today. That said, he hasn't updated yet today...

There's been a few guesses at monday's Java puzzler. talismancer is right in that the code won't work. olego and pteppic took this a bit further, and correctly guessed that it'd throw an exception of some sort. Specifically, you get the following output:

Adding java.lang.Object@addbf1 at index 0
Adding java.lang.Object@42e816 at index 1
Adding java.lang.Object@9304b1 at index 2
Adding java.lang.Object@190d11 at index 3
Adding java.lang.Object@a90653 at index 4
Adding java.lang.Object@de6ced at index 5
Adding java.lang.Object@c17164 at index 6
Adding java.lang.Object@1fb8ee3 at index 7
Adding java.lang.Object@61de33 at index 8
Adding java.lang.Object@14318bb at index 9
Removing java.lang.Object@addbf1
Exception in thread "main" java.util.ConcurrentModificationException
	at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
	at java.util.AbstractList$Itr.next(Unknown Source)
	at Foo.emptyBarList(Foo.java:15)
	at Foo.main(Foo.java:24)

Line 15 is for (Object o : barList) {

At first this seems like an odd place to get an exception - there's no obvious code in this line. But it makes sense when you realise that the Java compiler rewrites that line into something like:

Iterator<Object> it = barList.iterator(); while (it.hasNext) {Object o = it.next();

Most of the standard Java collections explicitly state that structural modifications to the collection will generally cause any iterators to throw a ConcurrentModificationException. Fortuantly there is a way round this: you're permitted to modify the list via methods on the iterator object (like Iterator.remove()). The concurrent collections also won't throw an exception, as the iterators in those are designed to be fully thread-safe and cope with (but don't necessarily show the result of) structual changes.

The fix in this case is easy enough: rewrite the loop to explicitly create an Iterator object and call the remove() method on that. And then add a unit test so that the method is actually tested, rather than being left as a hidden bug until someone does a completely unrelated change and actually adds code to call it!

Well, once again I'm on a train heading towards Horsham. That means it's time for another LiveJournal post!

As is becoming traditional for ramblings on train journeys, here's another technology fail. First, a bit of theory.

Recently I've been doing a lot of programming in Java. Java, unlike C, is a garbage collected language. What this means is that you don't have to keep track of memory usage - instead, a garbage collector runs periodically and frees unused objects for you. Garbage collected environments tend to have less predictable performance than non-garbage-collected ones (as you have little if any control over when and how the garbage collector runs), but on the flip side memory leaks and heap corruption tend to be impossible.

Java's particular garbage collection system is a mark-sweep system. This happens in two steps. To begin with, the garbage collector starts with a set of root objects and follows all the references from those, marking everything it finds. At the end of this step it has marked every object that can be reached from somewhere in the code. It then sweeps through all the objects, and anything that's not marked it throws away. The downside to a mark/sweep system is that there's no guarantee about when an object might be freed (so you can't do anything interesting when the object is destroyed), but on the plus side it deals with circular references and there's no way for an object to become lost.

So, on to the technology fail. This particular fail was a memory leak that occurred after a long soak test. Actually, a better term would be a memory squirrel - it's impossible for memory to be leaked and forever lost, but what can happen is that objects are held on for far too long. In this case it was a linked list, which very quickly showed up in a heap dump as holding far too many objects.

What was happening was an interaction between two pieces of code. The first was, about 300 times a second, adding an item to the list. The second was removing items, but had been throttled to remove at most 100 items per second. This was actually rather tricky to find, as the leak only showed up after the soak test had been running for a few days. If you ran a test for a day, then stopped the load, then firstly the list didn't get full enough to become noticeable (the rest of the code was chewing through objects at a crazily fast rate, with the garbage collector running several times a minute), and secondly the second part of the code kept running so the memory used was constantly going down!

Something a colleague came up with at work the other day...

Consider the following Java classes:

public class FooBase {};

public class Foo extends FooBase {};

public class Bar {
  public Bar(FooBase) {
    System.out.println("Constructor Bar(FooBase) called");
  }

  public Bar(Foo f) {
    System.out.println("Constructor Bar(Foo) called");
  }
}

public class Test {
  public static void testSomething() {
    java.util.ArrayList<FooBase> list = new ArrayList<FooBase>();
    list.add(new Foo());
    FooBase item = list.get(0);
    Bar b = new Bar(item);
  }
}

Without compiling and running the program (because that would be too easy a way to solve this), what do you think will happen when you call Test.testSomething()?

My guess is that it will print "Constructor Bar(Foo) called", because while item is a reference of type FooBase the object being pointed to by item is actually of type Foo. But then the guy who came up with this pointed out that the output "Constructor Bar(FooBase) called" would also make sense, and if this were C++ that would be the expected output. The difference is all C++ knows is that it has a pointer to something that must be a FooBase, while Java knows that it has a pointer to something that is actually a Foo.

Today's discovery: Java will not flush file streams for you. If you open a BufferedWriter, write some stuff to it, and then don't call close() on it, then Java will happily throw the remains of the buffer away.

This is probably related to the lack of destructors in Java, and the complete and utter uselessness of Object.finalize() - the method that's like a destructor, except it only gets called if the garbage collector runs, and then only if the garbage collector feels like it.