Which two statements about reference casting and `instanceof` in Java 17 are correct? (Choose two.)
A. Casting a reference to a class type when neither that class nor the reference's compile-time class is a subtype of the other is rejected by the compilerCorrect answer
Two unrelated classes can share no instance under single inheritance, so no object could satisfy the cast and javac rejects it outright with incompatible types, with no run-time check reached.
B. Casting a reference whose compile-time type is a non-final class to an interface that the class does not implement compiles; any failure surfaces at run time as a ClassCastExceptionCorrect answer
A subclass of the non-final class could implement the interface, so an object satisfying the cast is conceivable; the compiler permits it and defers to a run-time check that throws ClassCastException.
C. An `instanceof` test whose right-hand type is a class unrelated to the operand's compile-time type simply evaluates to false at run time
Assumes instanceof is a purely run-time question that can answer false; when the two types are provably disjoint the test is a compile error, the same incompatible types error the cast gets.
D. Casting a reference whose compile-time type is a final class to an interface that the class does not implement compiles, and fails only at run time
Misses that final means no subclasses, so the set of objects satisfying the cast to an unimplemented interface is provably empty and the compiler rejects it - a compile error, not a run-time failure.
Explanation
Java splits cast checking in two. The compiler first asks whether the conversion is *possible for any object* the reference could hold; only conversions that survive that question get a run-time check.
Why `Casting a reference to a class type when neither that class nor the reference's compile-time class is a subtype of the other...` is correct: two unrelated classes can have no common instance (Java is single-inheritance for classes), so no object could ever satisfy the cast. javac rejects it outright with `incompatible types: P cannot be converted to Q` — there is no run-time check to reach.
Why `Casting a reference whose compile-time type is a non-final class to an interface that the class does not implement...` is correct: a *subclass* of that non-final class could implement the interface, so an object satisfying the cast is conceivable. The compiler therefore permits it and defers to a run-time check, which throws ClassCastException when the object turns out not to implement it.
Why the others are wrong:
`An `instanceof` test whose right-hand type is a class unrelated to the operand's compile-time type...` encodes the belief that `instanceof` is a purely run-time question that can always answer false. It is not: when the two types are provably disjoint, the test is a compile error, the same `incompatible types` error the cast gets.
`Casting a reference whose compile-time type is a final class to an interface that the class does not implement...` misses the significance of `final`. A final class has no subclasses, so the set of objects that could satisfy the cast is empty and the compiler can prove it — the cast is a compile error, not a run-time failure. That final/non-final split is the whole point of the pair.
Exam tip: ask "could any object at all satisfy this cast?" If provably not — unrelated classes, or a final class to an interface it does not implement — it is a compile error. If yes but not guaranteed, it compiles and risks ClassCastException. `instanceof` obeys the same castability rule, so an `instanceof` that "looks obviously false" may not compile at all.