• Post Reply Bookmark Topic Watch Topic
  • New Topic

Runtime resolution?  RSS feed

 
Daniel Cox
Ranch Hand
Posts: 231
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If a method:
  • can be inherited (it is not private) but is not inherited
  • can be overridden (it is not static or final) but is not overridden

  • Is the method call resolved at runtime or compile-time? For example is the drive() method call resolved at runtime or compile-time? Given that the class Car does not have a subclass.

    I suspect that if a method can be inherited and can be overridden, then the method call is resolved at runtime because even though a subclass does not exist at compile-time, the compiler cannot be sure that a subclass does not exist at runtime, for example, one might be dynamically loaded at runtime.
     
    Henry Wong
    author
    Sheriff
    Posts: 23295
    125
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Daniel Cox wrote:
    I suspect that if a method can be inherited and can be overridden, then the method call is resolved at runtime because even though a subclass does not exist at compile-time, the compiler cannot be sure that a subclass does not exist at runtime, for example, one might be dynamically loaded at runtime.


    First, the JLS doesn't really discuss "how", as that is an implementation detail. So, this is a discussion regarding implementation detail, and may change in the future... but as an implementation detail, it is mainly done as follows...

    The compiler will resolve the method, at compile time, purely based on the class type of the reference being used. It will also decide whether the call should be polymorphic based on reference too. However, the generated code doesn't call the method directly. The generated call, does an indirect call, based on a jump table that is part of the instance.

    Later, at runtime, when the instances are created, the jump tables are filled in. This way, when the indirect call is executed, it calls the right version of the method.

    Henry
     
    Daniel Cox
    Ranch Hand
    Posts: 231
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If I understand you correctly, you’re saying that there is always a compile-time resolution and a runtime resolution. With compile-time resolution, the compiler is never sure of the right version of the method that will be called at runtime. The right version of the method is always resolved at runtime when instances are created and the jump tables are filled in. If that's the case then early binding is not really a binding. The real binding always takes place at runtime. I'm trying to understand the difference between saying that methodA() is resolved at compile-time and methodB() is resolved at runtime.
     
    Paul Clapham
    Sheriff
    Posts: 22823
    43
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Daniel Cox wrote:If I understand you correctly, you’re saying that there is always a compile-time resolution and a runtime resolution.


    For instance methods, yes. I suppose it might be possible to make the compiler look for special cases where that isn't necessary, but really that just complicates things.
     
    Henry Wong
    author
    Sheriff
    Posts: 23295
    125
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Daniel Cox wrote:If I understand you correctly, you’re saying that there is always a compile-time resolution and a runtime resolution.


    I think that I may have added to the confusion. I did mention that the compiler "will also decide whether the call should be polymorphic based on reference", but I didn't explicit state that the rest of the description only applies if it is.

    So, static methods, or private methods, do not get resolved at runtime -- as there is no need to do so.

    Henry
     
    Daniel Cox
    Ranch Hand
    Posts: 231
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Henry Wong wrote:So, static methods, or private methods, do not get resolved at runtime -- as there is no need to do so.

    I suspect that final methods also don't get resolved at runtime because even though a subclass might inherit a final method, the method in the superclass is executed at runtime. In any case, it looks like the drive() method I posted earlier will get resolved at runtime.
     
    Campbell Ritchie
    Marshal
    Posts: 56529
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Henry Wong wrote:. . . the JLS doesn't really discuss "how", as that is an implementation detail. . . .
    Let's look in the JVM specification. That last link only seems to be a definition of overriding, so let's try invokevirtual. That llink confirms what Henry has told us, only we could actually understand Henry's post I see the JVMSpec can be as hard to understand as the JLS.

    There were four links in the JVMSpec index under overriding and none under polymorphism.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!