Puzzle: a cat has nine lives

[Istvan Kovacs]

Given the following code:

package org.kovacstelekes.techblog.catwithninelives;

public class CatsHaveNineLives {
    public static void main(String[] args) {
        Cat aCat = new Cat();
        System.out.println("Message from " + aCat + ": " + aCat.message());
        for (int i = 0; i < 9; i++) {
            aCat = null;
            System.out.println("Killed the cat. Message from " + aCat + ": " + aCat.message());
        }

        aCat = new Cat();
        System.out.println("Resurrected the cat. Message from " + aCat + ": " + aCat.message());
    }
}

Implement class Cat to produce output similar to the following:

Message from org.kovacstelekes.techblog.catwithninelives.Cat@8efb846: I'm a Cat with 9 lives
Killed the cat. Message from null: I'm a Cat with 8 lives
Killed the cat. Message from null: I'm a Cat with 7 lives
Killed the cat. Message from null: I'm a Cat with 6 lives
Killed the cat. Message from null: I'm a Cat with 5 lives
Killed the cat. Message from null: I'm a Cat with 4 lives
Killed the cat. Message from null: I'm a Cat with 3 lives
Killed the cat. Message from null: I'm a Cat with 2 lives
Killed the cat. Message from null: I'm a Cat with 1 life
Killed the cat. Message from null: I've run out of lives. Please resurrect me.
Resurrected the cat. Message from org.kovacstelekes.techblog.catwithninelives.Cat@2a84aee7: I'm a Cat with 9 lives

[Mike Simmons]

package org.kovacstelekes.techblog.catwithninelives;

public class Cat {
  private static int lives;
  
  public Cat() {
    lives = 9;
  }
  
  public static String message() {
    var message = lives > 0 ? "I'm a Cat with " + lives + " lives" : "I've run out of lives. Please resurrect me.";
    lives--;
    return message;
  }
}

[Istvan Kovacs]

I reviewed a junior colleague's code today, and found something that looked weird. That's what inspired the post. (No, we aren't working on a pet store application.  )

[Mike Simmons]

Yeah, there's a couple weird things there that I would not advocate in most code.

[Tim Cooke]

Do you have to leave the given code as it is? Surely this is a NullPointerException?

aCat = null;
System.out.println("Killed the cat. Message from " + aCat + ": " + aCat.message());

[Istvan Kovacs]

Yes, you have to leave the provided code as it is. And of course the real question is how to avoid the NPE.

[Campbell Ritchie]

aCat == null ? "No message" : aCat.message()? If the reference is null, you will have null printed out a few words earlier.

[Paul Clapham]

public class Cat() {
  public Cat() {
    // insert code here which prints out all of those messages, can't be bothered to spell them all out
    System.exit(0);
  }
}

[Liutauras Vilda]

Tim Cooke wrote:Surely this is a NullPointerException?

Well, not necessarily.

You can call a static method of a class, even though the variable itself referring to a null, the type information of variable is enough.

public class Test {

    public static void main(String[] args) {
        Test t = null;

        // Here it is
        System.out.println(t.msg());

        // Pretty much similar to this
        System.out.println(((Test)null).msg());
    }

    public static String msg() {
        return "No NPE";
    }
}

[Tim Cooke]

I should have known this was some language quirk thing. You got me.

[Campbell Ritchie]

Liutauras Vilda wrote:

Tim Cooke wrote:Surely this is a NullPointerException?

. . . You can call a static method . . .

Yes, you can; I hadn't noticed that part of the requirements. Of course, in design terms, that is a bit like the following technique to stop a lion clawing me to death.

[Campbell Ritchie]

How can I stop a lion clawing me to death?




Put my head in its mouth.

[Istvan Kovacs]

To be honest, I didn't write this just to show some corner case. What inspired this was a piece of badly written code I had reviewed. My initial code was to confirm a suspicion, then I prettied it up a bit to turn it into a puzzle I intended to be funny, as well as maybe teach others something about Java. It was not my intention to have anyone killed by a lion.

There was a unit test, which, along with the class under test, combined a rather bizarre set of annotations, and yet did not fail with an NPE. That was what got me to look closer. Here's what the original code (class + test class) looked like:

@Named
public class Foo {
    public static X getX(Bar bar, ...) {...}

    public static Y getY(Bar bar, ...) {...}
}

@RunWith(MockitoJUnitRunner.class)
@Import(Foo.class)
public class FooTest {
    @Inject
    private Foo fooToTest;

    @Mock
    private Bar barMock;

    @Test
    void getX() {
        X x = fooToTest.getX(barMock, ...);
        assertStuff(x);
    }

    @Test
    void getY() {
        Y y = fooToTest.getY(barMock...);
        assertStuff(y);
    }
}

[Campbell Ritchie]

Istvan Kovacs wrote:. . . It was not my intention to have anyone killed by a lion. . . .

Thank goodness for that!

[Jesse Silverman]

I wasted my time looking at Cleaner because I'd been thinking of that lately because we'd been discussing proper replacements of code where we thought we actually needed a .finalize() that wasn't broken.

That turned out to be a dead end, because the Cleaner's .run() is guaranteed to run at most once.

Then I was thinking some sort of inner class or lambda keeping something alive, it was still a dead-end.

When we are instructing people never to call static methods on references instead of ClassName.staticMethod(), I always show the case where the reference is null, but then we call a static method on it, and get no null pointer exception, because of syntax that belies the semantics.

So I would have gotten this right had I not recently been thinking about .fnialize() and Cleaner, because I was eminently aware of the possibility of calling methods on a null pointer when they are static.

So, phooey!  But Paul wins in my book for the ultimate "cheat" of "print what they want then .exit() before the sh*t hits the fan!!"

There are people who just hate Java, we don't have many of them here.

There are people who love Java and ignore its faults or foibles or weirdnesses.

There are those who love Java and know all its faults or foibles or weirdnesses and dark corners so they never write code that does something different than what it appears to do to the casual reader.

This is in that last category.

I had an interview where they showed me lots of "bad" Java code, asked what was wrong with it, how to fix it and exactly what would happen when it did run as it was.

I think I identified everything wrong with it, and all the better ways to write it.

This would suffice for doing code reviews of individuals less than perfect in Java.

For full credit, they wanted to know exactly what would happen if it was checked in and run.

I fell a little short of that a few times, because once I see code doing that I just fix it, I don't run it and analyze the behavior.

They probably went with someone who went all the way like that, and was able to describe the exact unwanted behavior and where it would show the subtle symptoms of misbehavior, which tests would catch it.

This would be necessary to find and fix such code after the fact.

This "puzzle" falls into that category.

If I saw a static method being called on a reference instead of a class, I would just change the code or make the developer "fix it".

Because we always say "Don't do this!" and we didn't see it in the code, I failed to realize that, and recognize that this, rather than some fancy Cleaner or .finalize() error was what was involved.

Very good "puzzler"!

[Campbell Ritchie]

Jesse Silverman wrote:. . . Cleaner's .run() is guaranteed to run at most once.

But Object#finalize() usually doesn't run more than once either.

. . . Very good "puzzler"!

Yes, it is.

[Paul Clapham]

Istvan Kovacs wrote:To be honest, I didn't write this just to show some corner case.

It definitely isn't a corner case. Something which we wish was in a corner where nobody would ever notice it and decide to use it, I suppose,