Is casting from Number to double allowed in Java 7? (Autoboxing)

Question

A colleague checked in this code:

    Number n = ...;
    double nr = n == null ? 0.0 : (double) n;

Another colleague then complained that this didn't compile, and that's what I would expect. However, it turned out that I already had pulled this code from SVN and everything worked fine. We all had our the Java version set to 1.7 in eclipse, and it turned out that the code compiles fine under eclipse 4.4.2 (Luna) but fails under 4.2.2.

I fixed the issue by replacing the cast by n.doubleValue().

Now the actual question is: why is this accepted in the first place? It should of course work when casting to Double instead of double, but I'd think that a direct cast from Number to double was disallowed. So, is this a bug in eclipse 4.2.2 that was fixed in the meantime, or does eclipse 4.4.2 silently accept code that should not compile (which would IMHO be a bug)?

Answer 1

With Java 7, the casting system had to be changed slightly with regards to primitive types in order to allow working with MethodHandles. When invoking a method handle, the javac compiler generates a so-called polymorhic signature which derives from the method handle's method signatures. These polymorphic signatures are created by hinting out a parameter's type with a casting. For example, when binding a method with a signature of double, long -> int, the following casting is required:

Number foo = 42d, bar = 43L;
int ignored = (int) methodHandle.invoke((double) object, (long) bar);

The source code signature of MethodHandle::invoke is however defined as Object[] -> Object, without directly casting a value to a primitive type, the polymorphic signature could not be generated.

Obviously, for this to be possible, the Java compiler had to be changed to allow such castings which were not previously legal. While it would - in theory - be possible to restrict this use of castings to methods that are annotated with @PolymorhicSignature, this would have resulted in a strange exception why it is now generally possible in javac where appropriate byte code is generated when not creating a polymorphic signature. Yet, primitive types still represent their own runtime types what was pointed out in the other answer that posted the generated byte code of such a casting outside of a MethodHandle

Object foo = 42;
int.class.cast(foo);

would result in a runtime exception.

However, I agree with the comments that this is not necessarily dicussed appropriately in the JLS but I found a thread mentioning this specification gap. It is mentioned that the specification should be updated accordingly once lambda expressions are put in place but the JLS for Java 8 does not seem to mention such castings or @PolymorphicSignature either. At the same time, it states that [a]ny conversion that is not explicitly allowed is forbidden.

Arguably, the JLS is currently lagging behind the javac implementation and the Eclipse compiler has surely not picked this up properly. You could compare this to some corner-cases of generic type inference where several IDE compiler behave differently that javac until today.