Compiler design decision for dynamic method invocation

Question

I asked about Compiler interpretation of overriding vs overloading on StackOverflow, and got good answers, but this led me to another question that I'm not sure is appropriate for SO, but I think is for here.

One should read the original question and accepted answer, but perhaps it's understandable just by looking at the code below:

public static void whatIs(Circle s)
{
    System.out.println("Circle");
}
public static void whatIs(Square s)
{
    System.out.println("Square");
}

and we attempt to call,

whatIs(shapes[0]); //array of Shape objects (interface implemented by Circle,Square)
whatIs(shapes[1]);

we will get two errors (one for Square and one for Circle) indicating that:

• method Driver.whatIs(Square) is not applicable
  • actual argument Shape cannot be converted to Square by method invocation conversion

As is suggested in my question, using instanceof can give the desired results, and as the answered suggested:

The compiler could auto generate code like

if (shapes[0] instanceof Circle)
{
    whatIs((Circle) shapes[0]); //prints "Circle"
}

but, it does not. Just to be clear, I know one can use an abstract class instead of an interface to achieve similar functionality, nonetheless, does anyone know why the Java compiler won't automatically do this for you? I'm not a compilers guy, but I have a feeling that this is not an opinion based question. I assume that there is a good reason for this decision.

Answer 1

Remember: Java does not do "dynamic method invocation", there is nothing dynamic about the invocation of an overload or override, these are invocations decided at compile-time.

The issue you're seeing is due to the fact that a base class lacks details of sub classes, thus the compiler cannot automatically convert a base class at compile time to any given sub class (without an explicit forced cast to ensure it's converted with the possibility of error if you use the forced cast on the wrong object).

I know that doesn't seem like the answer, but you have to recognize what the compiler's actually doing. When you say:

Shape someShape = functionThatReturnsACircle();
whatIs(someShape);

The compiler reads that you have an object of type Shape named someShape, and therefore it writes out IL to call the generic whatIs(Shape shape). It can't know until runtime that someShape will be a Circle. Even if you use new Circle() the variable could be reassigned to a Square before the whatIs call, it really can't know the subclass that will live in someShape. So at compile time it compiles it to call the only one it knows has a matching signature, which is the whatIs that takes a base class.

Granted at runtime it will know that the in-memory object is in fact a Circle, but the compiler already wrote out IL/ByteCode/MachineCode/what-have-you that instructs to call the base class form of whatIs, so what's done is already done there.

---

As for:

actual argument Shape cannot be converted to Square by method invocation conversion

Now that speaks to what I said at the top of this answer. The compiler simply cannot write out instructions to convert someShape to a Circle because as stipulated earlier, it does not have any certainty that it is a Circle. Further more, you cannot just naturally up convert a base class to a more specific class because for instance, a Shape only has getArea() and does not have Radius so there's no way to construct the Radius property's value automatically based on the available information in the base class.