Why does javac allow some impossible casts and not others?
Let us consider a generalization of your example:
List<String> strList = someMethod();
Date d = (Date) strList;
These are the main reasons why Date d = (Date) strList;
is not a compilation error.
The intuitive reason is that the compiler does not (in general) know the precise type of the object returned by that method call. It is possible that in addition to being a class that implements
List
, it is also a subclass ofDate
.The technical reason is that the Java Language Specification "allows" the narrowing reference conversion that corresponds to this type cast. According to JLS 5.1.6.1:
"A narrowing reference conversion exists from reference type
S
to reference typeT
if all of the following are true:"...
5) "
S
is an interface type,T
is a class type, andT
does not name afinal
class."...
In a different place, JLS also says that an exception may be thrown at runtime ...
Note that the JLS 5.1.6.1 determination is based solely on the declared types of the variables involved rather than the actual runtime types. In the general case, the compiler does not and cannot know the actual runtime types.
So, why can't the Java compiler work out that the cast won't work?
In my example, the
someMethod
call could return objects with a variety of types. Even if the compiler was able to analyze the method body and determine the precise set of types that could be returned, there is nothing to stop someone changing it to return different types ... after compiling the code that calls it. This is the basic reason why JLS 5.1.6.1 says what it says.In your example, a smart compiler could figure out that the cast can never succeed. And it is permitted to emit a compile-time warning to point out the problem.
So why isn't a smart compiler permitted to say this is an error anyway?
Because the JLS says that this is a valid program. Period. Any compiler that called this an error would not be Java compliant.
Also, any compiler that rejects Java programs that the JLS and other compilers say is valid, is an impediment to the portability of Java source code.
The cast is technically possible. It cannot easily be proven by javac that it is not so in your case and the JLS actually defines this as a valid Java program, so flagging an error would be incorrect.
This is because List
is an interface. So you could have a subclass of a Date
that actually implements List
disguised as List
here - and then casting it to Date
would be perfectly ok. For example:
public class SneakyListDate extends Date implements List<Foo> {
...
}
And then:
List<Foo> list = new SneakyListDate();
Date date = (Date) list; // This one is valid, compiles and runs just fine
Detecting such a scenario might not always be possible, as it would require runtime information if the instance is coming from, for example, a method instead. And even if, it would require much more effort for the compiler. The compiler only prevents casts that are absolutely impossible due to there being no way for the class-tree to match at all. Which is not the case here, as seen.
Note that the JLS requires your code to be a valid Java program. In 5.1.6.1. Allowed Narrowing Reference Conversion it says:
A narrowing reference conversion exists from reference type
S
to reference typeT
if all of the following are true:
- [...]
- One of the following cases applies:
- [...]
S
is an interface type,T
is a class type, andT
does not name afinal
class.
So even if the compiler could figure out that your case is actually provably impossible, it is not allowed to flag an error because the JLS defines it as valid Java program.
It would only be allowed to show a warning.
5.5.1. Reference Type Casting:
Given a compile-time reference type
S
(source) and a compile-time reference typeT
(target), a casting conversion exists fromS
toT
if no compile-time errors occur due to the following rules.[...]
If
S
is an interface type:
[...]
If
T
is a class or interface type that is not final, then if there exists a supertypeX
ofT
, and a supertypeY
ofS
, such that bothX
andY
are provably distinct parameterized types, and that the erasures ofX
andY
are the same, a compile-time error occurs.Otherwise, the cast is always legal at compile time (because even if
T
does not implementS
, a subclass ofT
might).
List<String>
is S
and Date
is T
in your case.