31

I was experimenting with enum, and I found that the following compiles and runs fine on Eclipse (Build id: 20090920-1017, not sure exact compiler version):

public class SwitchingOnAnull {
    enum X { ,; }
    public static void main(String[] args) {
        X x = null;
        switch(x) {
            default: System.out.println("Hello world!");
        }
    }
}

When compiled and run with Eclipse, this prints "Hello world!" and exits normally.

With the javac compiler, this throws a NullPointerException as expected.

So is there a bug in Eclipse Java compiler?

polygenelubricants
  • 376,812
  • 128
  • 561
  • 623

3 Answers3

27

This is a bug. Here's the specified behavior for a switch statement according to the Java Language Specification, 3rd Edition:

JLS 14.11 The switch Statement

SwitchStatement:
    switch ( Expression ) SwitchBlock

When the switch statement is executed, first the Expression is evaluated. If the Expression evaluates to null, a NullPointerException is thrown and the entire switch statement completes abruptly for that reason.

Apparently the bug in Eclipse has nothing to do with default case or enum at all.

public class SwitchingOnAnull {
    public static void main(String[] args) {        
        java.math.RoundingMode x = null;
        switch(x) {};

        switch((Integer) null) {};

        switch((Character) null) {
            default: System.out.println("I've got sunshine!");
        }       
    }
}

The above code compiles and runs "fine" on (at least some version of) Eclipse. Each individual switch throws a NullPointerException when compiled with javac, which is exactly as the specification mandates.

The cause

Here's javap -c SwitchingOnAnull when compiled under Eclipse:

Compiled from "SwitchingOnAnull.java"
public class SwitchingOnAnull extends java.lang.Object{
public SwitchingOnAnull();
Code:
 0: aload_0
 1: invokespecial  #8; //Method java/lang/Object."<init>":()V
 4: return

public static void main(java.lang.String[]);
Code:
 0: aconst_null
 1: astore_1
 2: getstatic     #16; //Field java/lang/System.out:Ljava/io/PrintStream;
 5: ldc           #22; //String I've got sunshine!
 7: invokevirtual #24; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
10: return

}

It seems that the Eclipse compiler gets rid of the entire switch constructs entirely. Unfortunately this optimization breaks the language specification.

The official words

The bug has been filed and assigned for fix.

Olivier Thomann 2010-05-28 08:37:21 EDT

We are too aggressive on the optimization.

For:

  switch((Integer) null) {};

we optimize out the whole switch statement when we should at least evaluate the expression.

I'll take a look.

Candidate for 3.6.1.

See also

polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • weird. how would Eclipse cause this bug? Doesn't Eclipse use java and javac behind the scenes? very interesting. – D.C. May 28 '10 at 06:09
  • 5
    That's funny. Some EDT developer was a bit *too* smart when implementing an optimization it seems. – aioobe May 28 '10 at 06:16
  • 1
    It doesn't seem to be registered as a bug: https://bugs.eclipse.org/bugs/buglist.cgi?type1-0-0=substring;field1-0-3=status_whiteboard;short_desc=compiler%20switch%20enum%20null;field0-0-0=product;field1-0-2=short_desc;type0-0-1=substring;field0-0-1=component;type1-0-1=substring;type1-0-2=substring;type1-0-3=substring;type0-0-3=substring;query_format=advanced;field0-0-3=status_whiteboard;short_desc_type=allwordssubstr;field0-0-2=short_desc;type0-0-0=substring;field1-0-0=product;type0-0-2=substring;field1-0-1=component . So you could create a ticket there. – VonC May 28 '10 at 06:58
  • 4
    @darren no. Eclipse has its own compiler, entirely separate from `javac`. Do a stackoverflow search for "eclipse javac" and you'll see there are a number of cases (especially related to generics) where they behave differently. – Tyler Jun 21 '11 at 20:13
  • 3
    @aioobe - You're correct, they're too smart. They implemented it in such a way that makes sense when the language definition doesn't. Throwing an exception rather than going to default is definitely retarded. Now I have to wrap a try/catch for a NullPointerException where the catch will do the exact same thing the default does. Edit: Actually, I'll insert a null check, it's quicker than waiting to catch the exception, particularly since it's expected. – ArtOfWarfare Dec 21 '12 at 17:20
4

Definitly. If we look at the chapter 14.11 of the java language specification, it clearly states (under 'discussion'):

The prohibition against using null as a switch label prevents one from writing code that can never be executed. If the switch expression is of a reference type, such as a boxed primitive type or an enum, a run-time error will occur if the expression evaluates to null at run-time.

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
  • 1
    I can imagine a better rule: 1. allow a `null` switch label not covered by `default`, 2. issue a warning/error whenever the `null` label is missing and the expression is not a primitive. 3. enjoy shorter code and zero risk of NPE in switch. – maaartinus Sep 11 '15 at 02:37
1

Yep. According to the JLS it's a bug:

If the switch expression is of a reference type, such as a boxed primitive type or an enum, a run-time error will occur if the expression evaluates to null at run-time.

aioobe
  • 413,195
  • 112
  • 811
  • 826