Section: Inheritance Heck

Size: px

Start display at page:

Download "Section: Inheritance Heck"

Osborne Armstrong
6 years ago
Views:

1 Section: Inheritance Heck Inheritance Heck (previously named slightly differently) refers to seemingly complex and contradictory behavior by the compiler and runtime system when resolving types and methods in Java programs. However, through a proper understanding of how the compiler does type checking and how the runtime system works, it is possible to be able to correctly predict the behavior of even the most complex examples. First, some rules: Compile Time Rules: You can assign up the inheritance hierarchy Foo b = new Bar(); Object o = new String("abc"); but not down the inheritance hierarchy Goo g = new Bar(); // Type mismatch: cannot convert from Bar to Goo String str = new Object(); // Type mismatch: cannot convert from Object to String Casting up or casting down is okay ((Object) anint).tostring(); ((Integer) obj).tostring(); ((Foo) c).one(); ((Bar) b).one(); However, casting sideways is not okay Object Integer Double ((Integer) adouble).tostring(); // Cannot cast from Double to Integer ((Double) anint).tostring(); // Cannot cast from Integer to Double Runtime Rule Casting below object's runtime type is not okay. Foo Bar Baz Goo Foo f = new Bar(); ((Goo)f).one(); // Bar cannot be cast to Goo (it does compile)

2 Recommended Process Here is a recommended process that should help derive the correct answers. 1) First consider how the compiler will react a. If, based on the compile-time type of the variable, can we cast that type to that type (if there is a cast involved)? b. And, once we do that cast, does that class type have a.method() method, either directly, or inherited from one of its superclasses, found by traversing up the inheritance tree? If yes to both, the code compiles. If either fails write CE for CompileTime Error 2) If the message compiles consider the following that could happen at runtime a. Based on the run-time type, which is the type of the actual object rather than the type into which it is stored, can that object be cast to the variable's class type? If yes, some message will be sent (code will run). Otherwise write RE for Runtime Error. The only time the answer would be "no" at runtime would be if you try to cast too far down the tree. 3) If there is no CE or RE, determine the output (answers can be selected from the table): The Java runtime starts with the run-time type. It finds which version of the method it should use by traversing back up the inheritance tree. It will always find the method, eventually. For static methods, the Java runtime starts with the compile-time type. Thus, the specific static method is figured out entirely by the compiler (there is no dynamic binding needed). Examples: Math.sqrt(double) or Integer.parseInt(String)

3 Here is an example hierarchy with many example problems. Here each method simply prints out its name. Object +tostring() + method 1( ) "C1 M1" + method 2( ) "C1 M2" + staticmethod( ) "C1 Static" +method2( ) "C2 M2" +method1() +method3( ) Super.method2() +"C2 M3" +tostring( ) "C2 ts" +staticmethod( ) "C2 Static" +method2( ) "C4 M2" +method3( ) method1()+"c4 M3" +method1( ) "C3 M1" +method3( ) "C3 M3" public class InheritanceHeckExample { public static void main(string[] args) { var1 = new (); var2 = new (); var3 = new (); Object var4 = new (); /*1*/ var1.method1(); // C1 M1 Answer: First, we determine var1 is of type (its compile-time type) and has a method1(), so it compiles. Then it executes at runtime (no casting errors). It looks at the run-time type () and traverses up the tree looking for the first class with the method and calls the first one it finds. In this case, it looks at and there is no method1() defined in, so it traverses up the tree (from to ) and looks at to see if it has a method1() which it does, so it executes that method.

4 Recall the class hierarchy: /*2*/ var2.method1(); // C1 M1 /*3*/ var3.method1(); // C3 M1 /*4*/ var4.method1(); // COMPILER ERROR Answer: First, we determine if var4 is of type Object (the compiler treats it as such), and since that class does not have a method1() it does not compile, and is considered a COMPILER ERROR. /*5*/ var1.method2(); // C2 M2 / C1 M1 /*6*/ var2.method2(); // C4 M2 /*7*/ var4.method2(); // COMPILER ERROR /*8*/ var1.method3(); // COMPILER ERROR /*9*/ var2.method3(); // COMPILER ERROR /*10*/ var3.method3(); // C3 M3 /*11*/ var4.method3(); // COMPILER ERROR /*12*/ System.out.println(var1); // C2 ts /*13*/ System.out.println(var2); (or another hex#) First looks at to see if there is a tostring( ) method. Then, looks at to see if it has a tostring( ). It finds that it does not and looks in the Object class finds that it has one and executes the method. Object /*14*/ ()var1.method3(); // COMPILER ERROR Answer: First, we determine var1 is of type which does not have a method3() so it does not compile. The cast is not explicit, so the compiler still treats var1 as a object.

5 /*15*/ (()var2).method2(); // RUNTIME ERROR Answer: First, we determine the compile-time type of var2 () and then determine that this cast to this type to is legal. has a method2( ), so it compiles. Then considering the run-time type of var2 (), can we cast to? Since we cannot cast a to a, this is a RUNTIME ERROR and the method is not called on the object. /*16*/ (()var2).method2(); // C4 M2 Answer: First, we determine the compile-time type of the expression to the left of the period:. has a method2( ), so it compiles. Then at runtime, there are no casting errors because a run-time type can be cast to. It then starts from the run-time type, traversing up the tree looking for the first class with the method and calls the first one it finds. In this case, it looks at and there is a method2( ) defined there. /*17*/ (()var4).method1(); // RUNTIME ERROR Answer: var4 has a run-time type of. So this cast requests a cast downward, which is not allowed. /*18*/ (()var3).method2(); // C2 M2 / C3 M1 /*19*/ (()var1).method3(); // C1 M2 / C2 M3 /*20*/ System.out.println(()var1); // C2 ts Answer: This one compiles because it looks at var1, determines it is a legal cast and treats the argument to println as a object. Since has a tostring() method, it compiles. At runtime, the expression has a run-time type of, so it uses its method. /*21*/ System.out.println(()var1);// RUNTIME ERROR Answer: This one fails at runtime because it looks at var1, determines it is a legal cast (the compiler treats var1 as a object). The cast treats the argument as a object. Since inherits a tostring( ) method (all objects do), this line compiles. At runtime, it then determines that var1 has a run-time type of, which cannot be cast to (this is called a cross cast, and is disallowed in Java).

6 /*22*/ var1.staticmethod(); // C1 Static Answer: Static methods (and fields) are treated quite differently in Java. The compiler figures out everything at compile time. Here, var1 has a compile-time type of, so its static method is used. Note that the run-time type of var1 () is not important, nor is it relevant that has its own staticmethod(). /*23*/ var2.staticmethod(); // C1 Static Answer: var3 has a compiler type of, so the same staticmethod() is used here. /*24*/ var3.staticmethod(); // C2 Static Answer: var3 has a compile-time type of, which has its own staticmethod(). /*25*/ var4.staticmethod(); // COMPILER ERROR Answer: var4 has a compile-time type of Object, which has no staticmethod(). (The fact that its run-time type is, which does have a staticmethod() is not relevant.) /*26*/ (()var1).staticmethod(); // C2 Static /*27*/ (()var1).staticmethod(); // RUNTIME ERROR Answer: var1 has a compile-time type of, which can sometimes be cast to, which has a staticmethod(), so everything is fine at compile-time. In fact, the compiler notes that s staticmethod() is to be used. At runtime, var1 has a runtime type of, which cannot be cast to (as it would be a cross-cast). So the problem is with the cast, not the call to the static method. /*28*/ ((Object)var1).staticmethod(); // COMPILER ERROR Answer: You tell me! var1 has a type of, which has a staticmethod(). So why does this generate a compiler error. (Hint: run-time or compile-time type? Does that even matter?)

CSc 335 Inheritance Hell

CSc 335 Inheritance Hell Inheritance Hell refers to seemingly complex and contradictory behavior by the compiler and runtime system when resolving types and methods in an inheritance hierarchy. However,