Re: Question re testing constructor
Ian Shef <invalid@avoiding.spam> wrote in
news:Xns9FB45B83313A1vaj4088ianshef@138.125.254.103:
Lew <lewbloch@gmail.com> wrote in
news:26281492.354.1323270874867.JavaMail.geo-discussion-forums@pret21:
Ian Shef wrote:
Discussion: The JLS seems to treat casting separately from the
operations (such as calling a method) that would follow a cast. It
"feels like" this doesn't need to be the case. Thus I agree with
Stefan that it "feels like" the compiler or an IDE could catch this at
compile time (Eclipse does not) if the JLS permitted or required it.
Perhaps someone can explain why this is not the case.
Short answer: Because despite its best efforts, the compiler cannot
cure stupidity.
Agreed.
The compiler likely sees this as not different from
'((PrintStream)variable).println()', i.e., as a candidate for a
'NullPointerException' rather than a compiler error.
That would seem to be the intent of the JLS. The compiler follows the
rules laid down by the JLS.
On the other hand, there are many places in the JLS where constants or
literals are treated specially, and where responsibility is shared
between the compiler and the JVM. Casts are not treated this way and
are the responsibility of the JVM (with some minor exceptions, such as
when the compiler can guarantee that a cast is unnecessary e.g., a
widening reference conversion).
My preference is to find such errors as early as possible. However, the
compiler can't save programmers from all folly. _Java Puzzlers_ by
Joshua Bloch and Neal Gafter has other examples where a cast is
"obviously" an error but it won't be caught until run time. [My copy
of the book is currently 25 miles away, so I can't provide a more
precise reference.]
I now have the book in my hands (5th Printing June 2008). The third
program in "Puzzle 50: Not Your Type" looks like this:
public class Type3 {
public static void main(String args[]) {
Type3 t3 = (Type3) new Object();
}
}
Any typos are mine, not the authors'.
SPOILER ALERT
This program compiles but fails at run time. The compiler (per the JLS)
requires that Object be a subtype of Type3, or vice versa.
The authors write "Although it is obvious to us that this cast will fail,
the type system is not powerful enough to know that the run-time type of
the expression new Object() cannot be a subtype of Type3. Therefore, the
program throws a ClassCastException at run time."
The first and second programs of this puzzle involve instanceof, which has
behavior which is closely related to that of the cast operator. Although
the programs are quite simple, the results are counterintuitive (but in
accordance with the JLS).