The constructor of Egg throws a NullPointerException if it’s not given a (non-null) Chicken, and vice versa for the Chicken constructor. So how can you get a reference to either of them?

A common flaw that makes this possible (and even happen by accident) is calling a method that can be overridden in a subclass from a constructor. But that’s not the case here. There’s one method you can override that the constructor doesn’t call, but Java calls eventually: finalize(). That method is called before an object is garbage collected, to give it a chance to clean up its resources. It is called even if the constructor threw an exception, so by overriding it we can get a reference to an egg that wasn’t fully created.

package creator;

import chicken.Chicken;
import chicken.Egg;

public class Creator {
    static class FirstEgg extends Egg {
        FirstEgg() {
            super(null);
        }

        @Override
        protected void finalize() {
            new Chicken(this).ask();
        }
    }

    public static void main(String[] args) throws Exception {
        try {
            new FirstEgg();
        } catch (NullPointerException e) {
        }

        // there are ways to force garbage collection harder,
        // but this works good enough for me
        System.gc();
        System.runFinalization();
        Thread.sleep(1000);
    }
}

It’s well known that the finalization mechanism has several problems, and there are better alternatives. There are multiple ways to defend against this listed on the this secure coding standard for Java. Another way is to throw the exception before calling the constructor from the Object class. That means doing the work before calling super() (or another constructor with this()). Since Java 6, this guarantees that finalize() won’t be called. For example here we dereference mom.first before calling this(Object) to ensure you cannot create an egg without a mommy:

public class Egg {
    final Object first;

    public Egg(Chicken mom) {
        this(mom.first);
    }

    private Egg(Object first) {
        this.first = first;
    }
}

Congrats to the 17 people who found it. Matt Nathan was the first but it’s still a mystery if he’s a chicken, an egg or a null.

P.S.: The puzzles are taking a short vacation. They’ll continue in a few weeks.

What if every egg got the secret answer to that question imprinted from the chicken that laid it?

package chicken;

public class Egg {
    final Object first;

    public Egg(Chicken mom) {
        first = mom.first;
    }
}

And if then every chicken got that knowledge from the egg, passing it on from generation to generation. Then we could just ask any chicken!

package chicken;

public class Chicken {
    final Object first;

    public Chicken(Egg egg) {
        first = egg.first;
    }

    public void ask() {
        // The goal is to reach this line
        System.out.println("First there was the " + first);
    }
}

Now all you need to figure out is how to create the egg to create the chicken to create the egg to create chicken to ask the question.
Here’s a naive attempt that will throw a NullPointerException. Can you edit it to make it work?

package creator;

import chicken.Chicken;

public class Creator {
    public static void main(String[] args) {
        new Chicken(null).ask();
    }
}

The same rules and system as usual apply: you must run with the security manager enabled (-Djava.security.manager). Your solution must be in the creator package. If you found the solution, post it as a comment here below. These comments stay private, and become public later on the next blog post.

Good luck solving the mystery!

package game;

public final class Game {

    private final Ball ball = new Ball();
    private volatile long score;

    public final class Ball extends Throwable {
        private volatile long caught;

        private Ball() {
        }

        public synchronized void caught() {
            if (caught++ < score++) {
                // The goal is to reach this line
                System.out.println("You cheated!");
            }
        }
    }

    public void play() throws Ball {
        throw ball;
    }
}

The approach

If you couldn’t throw a ball, it wouldn’t be any fun. But extending Throwable also makes it implements Serializable, and that’s where the real fun starts. Using serialization, we can create a ball that supposedly has been caught as many times as our serialized data claims.

The Game looks like it spoils the fun. You can’t throw it; but more importantly you can’t serialize it. If you try to naively serialize a ball directly, it will also try to serialize the game it is attached to, leading to a NotSerializableException.

Note that technically the reference from the ball to its game is just a field called something like this$0. With “attach” I mean assigning to that field. So this problem is equivalent to serializing an object that has a normal field that is not serializable.

The catch is that we don’t need to serialize the game and ball at all. We only need to deserialize the ball, and attach it to a Game. The Game instance doesn’t need to come directly from the serialized stream. We can put a substitute in its place, and override readResolve to replace it with a Game before it gets attached to the Ball.

Cheating in practice

There are multiple ways to create the raw data (byte array) that contains such a ball attached to a substitute game. Here’s mine; there are other ways in the comments below.
We create a class similar to Ball (Ba). We give it the same serialVersionUID as Ball and our desired caught value. It’s attached to our substitute implementing readResolve (Player). We serialize that and replace just the name of the Ba class with the Ball class. Converting the byte[] to a String and back allows us to use String.replace for that.
The name Ba is chosen so that play.Player$Ba has the same length as game.Game$Ball. Without that, directly replacing one with the other would corrupt the stream.

package play;

import game.Game;
import game.Game.Ball;

import java.io.*;

public class Player implements Serializable {

    public static void main(String[] args) throws Exception {
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        new ObjectOutputStream(bos).writeObject(new Player().new Ba());
        byte[] bytes = new String(bos.toByteArray(), "ISO-8859-1")
                .replace("play.Player$Ba", "game.Game$Ball")
                .getBytes("ISO-8859-1");
        Ball ball = (Ball) new ObjectInputStream(new ByteArrayInputStream(bytes))
                .readObject();
        ball.caught();
    }

    class Ba implements Serializable {
        static final long serialVersionUID = -7172046060844866133L;

        private long caught = -1;
    }

    Object readResolve() {
        return new Game();
    }
}

This is what happens:

• When calling readObject(), first the Ball gets deserialized, and caught set to -1.
• The value for Ball.this$0 that gets deserialized is an instance of Player.
• Before Player gets assigned to that field (which would fail, because it’s of the wrong type), its readResolve method is called, creating a new Game with score 0
• That Game gets assigned to Ball.this$0, and readObject() returns the Ball.
• ball.caught() is called with caught == -1 and this$0.score == 0, and you are caught cheating!

Conclusion

Creating serializable objects that have a reference to a non-serializable object is a bad idea because you cannot serialize them. But with some dirty tricks, you can still deserialize them.

Java serialization is full of nasty unexpected possibilities. You could do a whole series of puzzles about just that. But if you’re really into that nastiness, all you need to do is look at the JDK security vulnerabilities over the last years.

package game;

public final class Game {

    private final Ball ball = new Ball();
    private volatile long score;

    public final class Ball extends Throwable {
        private volatile long caught;

        private Ball() {
        }

        public synchronized void caught() {
            if (caught++ < score++) {
                // The goal is to reach this line
                System.out.println("You cheated!");
            }
        }
    }

    public void play() throws Ball {
        throw ball;
    }
}

The same rules as usual apply; you must run with the security manager enabled (-Djava.security.manager). Your solution also must be in the play package. Putting anything else in the game package is not allowed.

If you found it, post your solution as a comment. These comments stay private, and become public later on the next blog post.

No liquids are allowed in your hand luggage:

package liquid;

import java.lang.String;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;

public class Luggage {
    private final Collection<String> items;

    public Luggage(Collection<String> items) {
        items = Collections.unmodifiableCollection(new ArrayList<String>(items));
        for (String item : items) {
            if (item.contains("liquid")) {
                throw new SecurityException("No liquids allowed in your hand luggage!");
            }
        }
        this.items = items;
    }

    public Collection<String> getItems() {
        return items;
    }

    public void fly() {
        if (items.contains("liquid water")) {
            // The goal is to reach this line
            System.out.println("Oh no, water on a plane! We're all going to die!");
        }
    }
}

Can you, as a thirsty passenger, take some water with you anyways? Leave your answer in a comment. The comments will stay private for a while, and be published later in the next blog post.. Try to solve it, and then look at the solutions in the comments below!

Update: comments were briefly not moderated, already showing the solution immediately; sorry for that.
Update: Let’s try to do it differently from the other puzzles then! Only look at the comments below after you’re tried to solve it yourself!

package car;

public final class Car {
    private final int MAX_SPEED = 100;

    private int speed = 0;

    public synchronized void accelerate(int acceleration) {
        speed += acceleration;
        if (speed > MAX_SPEED)
            crash();
    }

    public synchronized void crash() {
        speed = 0;
    }

    public synchronized void vroom() {
        if (speed > MAX_SPEED * 10) {
            // The goal is to reach this line
            System.out.println("Vroom!");
        }
    }
}

Lesson to all you racers out there: We want the car to accelerate a lot (speed += acceleration must execute), but not do that thing where it hits the tree and comes to a full stop (speed = 0 must not execute).

What can happen between those two statements? The if (speed > MAX_SPEED) doesn’t help us any further, because speed really needs to be higher than MAX_SPEED. So all that’s left is the call to the crash() method. That one has to fail: We want crash() to crash!

We can do that by making sure there’s not enough space left on the stack to be able to call any method. If the stack is almost full when we call accelerate, we get a StackOverflowError on the call to crash(). How do we get the stack to be almost full? One way is to just brute-force it: an infinitely recursing method that just keeps trying.

package driver;

import car.Car;

public class Driver {
	private static Car car = new Car();

	public static void main(String args[]) {
		try {
			recurse();
		} catch (StackOverflowError e) {
		}

		car.vroom();
	}

	public static void recurse() {
		car.accelerate(1001);
		recurse();
	}
}

And that works!… On some systems at least. A problem here is that if you’re trying to accelerate so much and keep on crashing (after 1500 crashes on my system), the JVM does something no car maker ever would: it optimizes the car to ensure it can crash really fast. It in-lines the call to crash(), reducing it to essentially if (speed > MAX_SPEED) speed = 0;. That eliminates the possibility of a StackOverflowError.

We can work around that by being just a little gentler on the car: crash it a bit less, so the JVM doesn’t decide to optimise that. First grow the stack until it’s getting close to where it needs to be, and only then add the car into the equation. But the only way to know you’re getting close to the limit is by hitting it. Therefor we recurse without the car until we hit the stack overflow, then take a few steps back, and then apply the brute-forcing solution from above:

package driver;

import car.Car;

public class Driver {
    static Car car = new Car();
    static int a = 0;

    public static void main(String args[]) {
        recurse();
        car.vroom();
    }

    static void recurse() {
        try {
            recurse(); // recurse without the car
        } catch (StackOverflowError e) {
            // when we've hit the limit of the stack, just go back out
        }
        if (a++ == 10) { // after taking 10 steps back
            recurse2(); // recurse with the car
        }
    }

    static void recurse2() {
        car.accelerate(1001);
        recurse2();
    }
}

An alternative solution is to use Thread.stop. But it’s quite hard to time it right; it doesn’t work that reliable across systems. At first I expected it to be impossible in practice, but I was proven wrong. You can see the code in the comments below.
You do need a special permission to call that method, but that’s one of the very few things included in the default security policy file. The only other permissions in there are opening listening sockets on high ports, and reading some standard system properties.

Conclusion

Not many succeeded in solving this one. The ones who did, and their solutions can be admired below as time-travelling comments that were posted before this blog post appeared.

The fact that this hack is possible makes me wonder. Is all privileged code in Java itself really prepared to crash at any time? Including all native code? If an applet makes the loading of a class fail in this way; does that cause NoClassDefFoundErrors in other applets? How else could this be abused?…

Please, don’t try this at home. Car insurance usually doesn’t cover the failing of the crashing of the crash. Even if you first tried crashing without the car; running with your head straight into the tree. Blowing up the car right before it hits the tree is not appreciated either.

In the next puzzle we’ll sneak some goods passed airport security, so stay tuned!

    public synchronized void accelerate(int acceleration) {
        if (acceleration > MAX_SPEED - speed)
            crash();
        else
            speed += acceleration;
    }

How do we make this go over the speed limit?
The flaw is in the check of the acceleration: it checks if it’s too high, but it forgot to check if it’s too low. Put your gearbox in reverse, push the pedal to the metal (Integer.MIN_VALUE), and the speedometer will wrap around.

Car car = new Car();
car.accelerate(-1);
car.accelerate(Integer.MIN_VALUE);
car.vroom();

First we give it a little tap to set speed to -1. Then we push it all the way: the check if Integer.MIN_VALUE > 99 passes, giving us -1 + Integer.MIN_VALUE. That causes an underflow, putting the car in its real top speed: Integer.MAX_VALUE.

Let’s avoid that kind of mistake, by checking the resulting speed instead of the acceleration:

package car;

public final class Car {
    private final int MAX_SPEED = 100;

    private int speed = 0;

    public synchronized void accelerate(int acceleration) {
        speed += acceleration;
        if (speed > MAX_SPEED)
            crash();
    }

    public synchronized void crash() {
        speed = 0;
    }

    public synchronized void vroom() {
        if (speed > MAX_SPEED * 10) {
            // The goal is to reach this line
            System.out.println("Vroom!");
        }
    }
}

Can you still break the speed limit in this car?

The solutions (yes, that’s plural) to this are not always very reliable. How good they work may depend on the environment they’re running in. But with some tweaks and the right approach, it is possible to build a solution that should work all the time in practice without taking any significant time. 175 people solved the first part, but so far only 11 broke this part. If that doesn’t scare you off, good luck! You can try out your solution on this ugly site.

The solutions will follow tomorrow are available.

This car crashes if you accelerate too much. But can you make it go ten times faster than its limit?

package car;

public final class Car {
    private static final int MAX_SPEED = 100;

    private int speed = 0;

    public synchronized void accelerate(int acceleration) {
        if (acceleration > MAX_SPEED - speed)
            crash();
        else
            speed += acceleration;
    }

    public synchronized void crash() {
        speed = 0;
    }

    public synchronized void vroom() {
        if (speed > MAX_SPEED * 10) {
            // The goal is to reach this line
            System.out.println("Vroom!");
        }
    }
}

As a driver, do what needs to be done to push the car over its limit. Anything in your code is allowed; any trick outside the code is not. You must run with -Djava.security.manager, so setAccessible won’t work. If in doubt, read the exact rules.

package driver;

import car.Car;

public class Driver {
    public static void main(String args[]) {
        // TODO break the speed limit
        Car car = new Car();
        car.accelerate(1001);
        car.vroom();
    }
}

If you’ve found the solution, post it into the ugly form over there. There it will be compiled and ran, and if it works, you will be directed to part two.

To be notified of when the solution and next puzzles come out, follow the rss feed or twitter.

package sleep;

import dream.Dream;

public class Sleeper {
	private int level;

	public synchronized int enter(Dream dream) {
		level++;
		try {
			dream.dream(this);
		} finally {
			level--;
		}
		return level;
	}
}

package sleep;

import dream.Dream;

public class Main {
	public static void main(String[] args) {
		if (new Sleeper().enter(new Dream()) != 0) {
			// The goal is to reach this line
			System.out.println("Am I still dreaming?");
		}
	}
}

Solution

The synchronized on the dream method means that it takes the monitor (lock) of the Sleeper object when we enter it, and it releases it again when we leave it. No other thread can enter the method while the monitor is held.

But here’s the catch: the monitor isn’t necessarily held all the time while the method is running. With Object.wait you can release a monitor in the middle of a synchronized method.

How do we apply that to solve this puzzle? When we enter the outer dream, we use wait to release the monitor. But first we launch a separate thread, that will also enter a dream. Entering that inner dream makes the second thread take the monitor. So in the inner dream, we use wait a second time to release the monitor. That allows the main thread stop waiting, take the monitor back, and leave the outer dream. And there we are: we have woken up from the outer dream, back where we started in main, but the dream within the dream goes on in the second thread.

package dream;

import sleep.Sleeper;

public class Dream {
	private static void doWait(Sleeper s) {
		try {
			s.wait(200);
		} catch (InterruptedException e) {
		}
	}

	public void dream(final Sleeper s) {
		new Thread() {
			public void run() {
				s.enter(new Dream() {
					@Override
					public void dream(Sleeper s) {
						doWait(s);
					}
				});
			}
		}.start();

		doWait(s);
	}
}

And the winner is…

I got more answers than I expected. The first one came from David Shay. Congrats!

It’s a bit repetitive, but as promised, you can see and compare all dreams as comments below this post.

Conclusion

The moral of the story: synchronized on a method doesn’t mean two different threads can’t be in it at the same time. It only ensures that such threads cannot execute concurrently; at least one of them must be waiting.

You can prevent this kind of abuse and other problems, by using a private object as monitor:

public class Sleeper {
	private final Object lock = new Object();

	public int dream(Dream dream) {
		synchronized(lock) {
			...
		}
	}
}

But that still leaves me unsure if I actually woke up this morning.

We’ve learned our lesson from the clowns: There are no hidden calls behind the scenes here, and we embrace recursion; we count on it.

Have you ever woken up from a dream, to then discover that you’re actually still dreaming? If you then wake up, how do you know you’re back in reality? This puzzle implements a solution to that problem: you count the recursion level of your dreams as you enter and exit them:

package sleep;

import dream.Dream;

public class Sleeper {
	private int level;

	public synchronized int enter(Dream dream) {
		level++;
		try {
			dream.dream(this);
		} finally {
			level--;
		}
		return level;
	}
}

A sleeper starts sleeping and enters a dream (level one). He can have a dream within that dream, and even enter deeper dreaming levels. But when he leaves the outer dream, he’s awake again, so he should be at level zero again, right?

package sleep;

import dream.Dream;

public class Main {
	public static void main(String[] args) {
		if (new Sleeper().enter(new Dream()) != 0) {
			// The goal is to reach this line
			System.out.println("Am I still dreaming?");
		}
	}
}

The counting of the levels looks really safe, so this seems impossible:

• Every time you enter a dream level is increased. Because of the finally block, there’s no way to leave a dream without decreasing it again.
• The synchronized block makes sure no other thread can call it concurrently. The level is returned from the dream method to make sure it’s read within the synchronized block.
• dream is the very first thing that’s called on the Sleeper, so the level must be zero when entering it. The value that’s returned from it must be zero too then, because even if we call it recursively we must enter as many dreams as we exit.

// this is the only file you're allowed to edit
package dream;

import sleep.Sleeper;

public class Dream {
	public void dream(Sleeper s) {
		// TODO implement me
	}
}

Do you eat Java, breathe Java, and even dream in Java? Can you find the flaw in this reasoning? Can you imagine a really weird dream, that would make the sleeper lose count? If so, leave your code in a comment here!

To give everyone a fair chance, those comments will stay were hidden for a while. They will become public soon are now public, together with a follow-up blog post.
To be notified of that and the next puzzles, follow the feed or twitter.

PS: This puzzle is appearing simultaneously in the Java Specialists’ Newsletter.