This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
First let me say that this study guide is excellent. Material is covered in an entertaining style that makes it easy to keep reading. I bought my copy yesterday, and checking the errata page, all errata except the 03/03 fix were corrected in my copy of the book. The following point was not on the errata list. My point concerns the chapter 3 self test, question 2: [code ommitted] "which two of the following statements, inserted independently, could legally be inserted into line 5 of this code? (Choose two.)" There are 3 of the answers that can be legally inserted. In the answer key, answer F: boolean test = (t instanceof String); is said to be incorrect because "the String class is not in the hierarchy of the t object". The fact that the instanceof test would return false does not make it illegal. Am I missing something, or is this errata?
here's the full text so people can understand what Bryan is questioning:
which of the following statements, inserted independently, could legally be inserted into line 5 of this code? (chose two) A. boolean test = ( Component instanceof t ); B. boolean test = ( t instanceof Ticker ); C. boolean test = t instanceof( Ticker ); D. boolean test = ( t instanceof Component ); E. boolean test = t.instanceof( Object ); F. boolean test = ( t instanceof String );
Originally posted by Bryan Helm: is said to be incorrect because "the String class is not in the hierarchy of the t object". The fact that the instanceof test would return false does not make it illegal. Am I missing something, or is this errata?
... so right away, the compiler is going to be able to tell if there's even a *chance* that an object could be an instanceof a particular class. like t instanceof Component -- the compiler knows there's a relationship between the two, so its possible that t could be an instance of Component. But it won't know for sure until runtime. BUT... with t instanceof String -- the compiler can look at that and RIGHT AWAY know that there's no way that t could be an instanceof String -- there's NO relationship between those two classes at all. So it throws a comiple-time error. Get it? [ April 07, 2003: Message edited by: Jessica Sant ]
Joined: Apr 07, 2003
Thanks for taking the time to be more complete. I thought I had enough to illustrate the problem, but that was part of my wrong assumption. I take it the lesson to be learned here is that instanceof is not just a binary operator that compares an instance and a class then returns a boolean (as I had assumed), but is handled differently by the compiler than other binary operators that return a boolean value, and to ask if something is an instanceof a class or interface when the compiler can determine it is not is a compile-time error. Also, mea culpa for not trying the example with a compiler before asking.
Joined: Apr 07, 2003
For completeness, this is covered in section 15.20.2 of the JLS. instanceof behaves as if the first operand is cast to the second. If the cast would fail at compile time, so does instanceof. Otherwise it fails or suceeds at runtime based on whether or not a cast would throw a ClassCastException. Cast behavior is specified in JLS section 15.16: "Not all casts are permitted by the language. Some casts result in an error at compile time. For example, a primitive value may not be cast to a reference type. Some casts can be proven, at compile time, always to be correct at run time. For example, it is always correct to convert a value of a class type to the type of its superclass; such a cast should require no special action at run time. Finally, some casts cannot be proven to be either always correct or always incorrect at compile time. Such casts require a test at run time." [ April 07, 2003: Message edited by: Bryan Helm ]