Java 8 autoboxing + generics: different behaviour with variable vs. method

Question

I found a piece of code that after switching from Java 7 to Java 8 stopped compiling. It does not feature any of the new Java 8 stuff like lambda or streams.

I narrowed the problematic code down to the following situation:

GenericData<Double> g = new GenericData<>(1d);
Double d = g == null ? 0 : g.getData(); // type error!!!

You can probably guess that GenericData's constructor has one parameter of that generic type and the getData() method returns just that generic type. (For the complete source code see below.)

Now what bothers me is that in Java 7 that code compiled just fine whereas with Java 8 I get the following error:

CompileMe.java:20: error: incompatible types: bad type in conditional expression
Double d = g == null ? 0 : g.getData();
                       ^
int cannot be converted to Double

It seems that Java 7 was able to do the transition from int -> double -> Double, but Java 8 fails with trying to immediately go from int -> Double.

What I find funny in particular is that Java 8 does accept the code when I change it from getData() to data, i.e. access the GenericData's value via the variable itself instead of the getter-method:

Double d2 = g == null ? 0 : g.data; // now why does this work...

So the two questions I have here are:

1. Why doesn't Java 8 infer the types like Java 7 and cast my int to double before autoboxing double to Double?
2. Why does that problem only occur with the generic method but not the generic variable?

Complete source code:

public class CompileMe {
    public void foo() {
        GenericData<Double> g = new GenericData(1d);
        Double d = g == null ? 0 : g.getData(); // type error!!!
        Double d2 = g == null ? 0 : g.data; // now why does this work...
    }
}

class GenericData<T> {
    public T data;
    public GenericData(T data) {
        this.data = data;
    }
    public T getData() {
        return data;
    }
}

To test it run the compiler as follows:

javac -source 1.7 -target 1.7 CompileMe.java   # ok (just warnings)
javac -source 1.8 -target 1.8 CompileMe.java   # error (as described above)

Finally in case it matters: I run Windows 8 and Java 1.8.0_112 (64-bit).

Mo

Just for the record: you are using a raw type in there; on the line g = new GenericData. Probably not the root cause, but for sure doesn't help. And btw: I just repro'ed the issue with IBM JDK 1.8 ... really interesting. – Distraught

@Mo really interesting, by the way compiles fine with latest jdk-9 – Hesterhesther

Try to have a look at this SO question: Java 8 and Generalized Target-Type Inference – Bodhisattva

@Distraught Thanks for pointing that out. Probably a typo while I was simplifying the original code. (It does indeed not change the outcome: That type error when compiling still exists.) – Mo

@Mo you could add g == null ? 0d : g.getData(); make zero a double there and it will work, but overall seems like a compiler bug. – Hesterhesther

@Bodhisattva Thank you, but to be honest, I don't exactly follow/understand the explanations in that SO question :-/ Only so much that it seems that generic types don't follow method call chains? But then why did it work in Java 7? – Mo

@Hesterhesther Yes, that works (using 0d), still the question remains... What has changed in Java 8 (while it still works in Java 7)... – Mo

Interestingly the version with g.data seems to unbox and immediately rebox it. If you pass a null to the GenericData constructor, the line with g.data will throw an NPE. Using 0d, the line with g.getData() passes, but the one with g.data still throws an NPE. – Unplug

@DidierL Good point! With Java 7 both versions throw NPEs--meaning both do the unbox & rebox dance. With Java 8 the method call (with 0d) does not throw NPE as you said, and instead results in outputting simply "null". That explains why one needs 0d instead of 0: Because no unboxing takes place and int can't be converted to Double implicitely. Still, why do the method call and the field access show different behaviour... – Mo

@Mo I got a little bit of advice from FindBugs ;-) – Unplug

according to JLS Chapter 15, specifically "Table 15.25-D" states that for 2nd operand int, 3rd operand Double the resulting type is bnp(int,Double) (binary numeric promotion) which in turn states "If any operand is of a reference type, it is subjected to unboxing conversion" -> the NPE is to be expected – Bilberry

FWIW, compiles and runs fine with in eclipse neon, Win10 – Bilberry

@Bilberry So the conclusion from not getting that NPE with Java 8 is there has to be a bug during runtime...? Still why does it not compile with the int value? – Mo

@Mo the way I read the JLS, it should compile, and the result type should be double. Possibly, the compiler infers the type of the 3rd operand to some other reference type, but I don't see a reason for this in the given snippet. – Bilberry

Answer 1

Method invocation expressions are special in that they may be Poly Expressions, subject to target typing.

Consider the following examples:

static Double aDouble() {
    return 0D;
}
…
Double d = g == null ? 0 : aDouble();

this compiles without any problems

static <T> T any() {
    return null;
}
…
Double d = g == null ? 0 : any();

here, the invocation of any() is a Poly Expression and the compiler has to infer T := Double. This reproduces the same error.

This is the first inconsistency. While your method getData() refers to the type parameter T of GenericData, it is not a generic method (there is/should be no type inference involved to determine that T is Double here.

JLS §8.4.4. Generic Methods

A method is generic if it declares one or more type variables

getData() doesn’t declare type variables, it only uses one.

JLS §15.12. Method Invocation Expressions:

A method invocation expression is a poly expression if all of the following are true:

• …
• The method to be invoked, as determined by the following subsections, is generic (§8.4.4) and has a return type that mentions at least one of the method's type parameters.

Since this method invocation is not a poly expression, it should behave like the example with the aDouble() invocation, rather than the any().

But note §15.25.3:

Note that a reference conditional expression does not have to contain a poly expression as an operand in order to be a poly expression. It is a poly expression simply by virtue of the context in which it appears. For example, in the following code, the conditional expression is a poly expression, and each operand is considered to be in an assignment context targeting Class<? super Integer>:

Class<? super Integer> choose(boolean b,
                              Class<Integer> c1,
                              Class<Number> c2) {
    return b ? c1 : c2;
}

So, is it a reference conditional or a numeric conditional expression?

§15.25. Conditional Operator ? : says:

There are three kinds of conditional expressions, classified according to the second and third operand expressions: boolean conditional expressions, numeric conditional expressions, and reference conditional expressions. The classification rules are as follows:

• If both the second and the third operand expressions are boolean expressions, the conditional expression is a boolean conditional expression.
  …
• If both the second and the third operand expressions are numeric expressions, the conditional expression is a numeric conditional expression.
  For the purpose of classifying a conditional, the following expressions are numeric expressions:
  • An expression of a standalone form (§15.2) with a type that is convertible to a numeric type (§4.2, §5.1.8).
  • A parenthesized numeric expression (§15.8.5).
  • A class instance creation expression (§15.9) for a class that is convertible to a numeric type.
  • A method invocation expression (§15.12) for which the chosen most specific method (§15.12.2.5) has a return type that is convertible to a numeric type.
  • A numeric conditional expression.
• Otherwise, the conditional expression is a reference conditional expression.

So according to these rules, not precluding generic method invocations, all of the shown conditional expressions are numeric conditional expression and should work, as only “otherwise” they are to be considered to be reference conditional expression. The Eclipse version, I tested, compiled all of them without reporting any error.

This leads to the strange situation that for the any() case we need target typing to find out that it has a numeric return type and deducing that the conditional is a numeric conditional expression, i.e. a stand-alone expression. Note that for boolean conditional expressions, there is the remark:

Note that, for a generic method, this is the type before instantiating the method's type arguments.

but for numeric conditional expression, there’s no such note, whether intentional or not.

But as said, this only applies to the any() example anyway, as the getData() method is not generic.

Stoup

mind me, but I've read your answer twice, still no obvious clue of why this still fails with the jdk-8 compiler. Bottom-line this is a jdk-8 compiler bug right? – Hesterhesther

@Eugene: exactly. The getData() case should compile, exactly like the aDouble() example. Whether the any() example should compile as well, is not so trivial to answer and it might be even the case that the intent of the specification doesn’t match its wording. – Stoup

good. I was sorting hoping you will bring some light here. Thx – Hesterhesther

@Stoup found Bug ID: JDK-8162708 - seems to match your observations here – Bilberry

Answer 2

This seems to be a known issue of the Oracle compiler: Bug ID: JDK-8162708

Quote:

A DESCRIPTION OF THE PROBLEM :
If you have a method in a generic class declared as follow:

class Foo<T> {
  public T getValue() {
    // returns a value ...
  }
}

and you call the method above inside a ternary operator as follow

Foo<Integer> foo = new Foo<>();
Float f = new Random().nextBoolean() ? foo.getValue() : 0f;

you get a syntax error from the javac 1.8 compiler.

But the code above compiles with no errors and warnings with both javac 1.7 and 1.9.

Resolution: Unresolved

Affected Versions: 8

From the Comments:

This issue is only applicable to 8u, there is no issue in 7 and 9

Bilberry

Answer 3

Have to claim this is not an answer, merely a reasoning. With my brief experience in compiler (not Javac specific), it could has something to do with how the code is parsed.

In the following decompiled code, you see either calling the method GenericData.getData:()Ljava/lang/Object or referring to field GenericData.data:Ljava/lang/Object, they both first get the value/method with Object returned, followed by a cast.

  stack=4, locals=4, args_size=1
     0: new           #2                  // class general/GenericData
     3: dup
     4: dconst_1
     5: invokestatic  #3                  // Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
     8: invokespecial #4                  // Method general/GenericData."<init>":(Ljava/lang/Object;)V
    11: astore_1
    12: aload_1
    13: ifnonnull     23
    16: dconst_0
    17: invokestatic  #3                  // Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
    20: goto          30
    23: aload_1
    24: invokevirtual #5                  // Method general/GenericData.getData:()Ljava/lang/Object;
    27: checkcast     #6                  // class java/lang/Double
    30: astore_2
    31: aload_1
    32: ifnonnull     39
    35: dconst_0
    36: goto          49
    39: aload_1
    40: getfield      #7                  // Field general/GenericData.data:Ljava/lang/Object;
    43: checkcast     #6                  // class java/lang/Double
    46: invokevirtual #8                  // Method java/lang/Double.doubleValue:()D
    49: invokestatic  #3                  // Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
    52: astore_3
    53: return

If compare the ternary operator expression with an equivalent if-else:

Integer v = 10;
v = v != null ? 1 : 0;

     0: bipush        10
     2: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
     5: astore_1
     6: aload_1
     7: ifnull        14
    10: iconst_1
    11: goto          15
    14: iconst_0
    15: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
    18: astore_1
    19: return

Integer v = 10;
if (v != null)
    v = 1;
else
    v = 0;

     0: bipush        10
     2: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
     5: astore_1
     6: aload_1
     7: ifnull        18
    10: iconst_1
    11: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
    14: astore_1
    15: goto          23
    18: iconst_0
    19: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
    22: astore_1
    23: return

There is no significant difference in the two versions. So I don't think there is a hidden secret doing all the black magic. It's a result of how the compiler parse the whole expression, and based on the context to figure out a type to make all components equally happy. E.g.,

Double val = 0; // compilation error: context is clear, 0 is an integer, so Integer.valueOf(i), but don't match expected type - Double
val = 0 + g.getData(); // OK, enough context to figure out the type should be Double

Still, the confusion is in that why the generic field works but not the generic method...

val = val == null ? 0 : g.data; // OK
val = val == null ? 0 : g.getData(); // Compilation error

EDIT: the document Holger quoted seems to be a good clarification.

Occidentalize

Answer 4

CompileMe.java:4: error: incompatible types: bad type in

conditional expression

      Double d = g == null ? 0 : g.getData(); // type error!!!

int cannot be converted to Double

Here 0 is integer and you are putting it inside Double.

Try this

public class CompileMe {
    public static void main(String[] args) {
        GenericData<Double> g = new GenericData(1d);
        Double d = g == null ? 0d : g.getData(); // type error!!!
        Double d2 = g == null ? 0d : g.data; // now why does this work...
        System.out.println(d);
        System.out.println(d2);
    }
}

class GenericData<T> {
    public T data;
    public GenericData(T data) {
        this.data = data;
    }
    public T getData() {
       return data;
    }
}

Or use double literal instead of Double wrapper class

    public class CompileMe {
    public static void main(String[] args) {
        GenericData<Double> g = new GenericData(1d);
        double d = g == null ? 0 : g.getData(); // type error!!!
        double d2 = g == null ? 0 : g.data; // now why does this work...
        System.out.println(d);
        System.out.println(d2);
    }
}

class GenericData<T> {
    public T data;
    public GenericData(T data) {
        this.data = data;
    }
    public T getData() {
        return data;
    }
}

Because widening and boxing will not take place simultaneously.

Cynthea