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

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!

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.

On one side of a river there are three misssionaries and three cannibals. There is a boat which can be used to transfer people from one side of the river to the other. No more than two people can fit in the boat and it must have at least one person in it during any transfer. The problem is to find the shortest sequence of transfers which gets all six people from one side to the other without ever creating a situation where missionaries outnumber cannibals on either side of the river. (The idea being that if this happens, the missionaries will then be able to corrupt the cannibals by 'converting' them.)