Question about early binding

[Jary316]

I need to find two kinds of method calls that use early binding in Java.

I would like to know if my ideas are correct:

I think overloaded functions uses early binding, because the compiler looks at the types of the parameter variables to match which function to call.
I think static functions uses early binding because they are outside of a class.
I think functions define as final uses early binding because they do not change.

Does that make sense? Are those correct method calls that uses early binding please?

Thank you for your help.

[neilcoffey]

I suppose there's no "correct" answer -- it depends on what the writers of your VM decided to do. But as far as I'm aware, the idea that VMs make optimisations based on the "final" keyword is a misconception.

To the VM, it doesn't matter whether a particular method has been declared final. What matters is whether or not it has been overridden at a particular moment. If the VM binds a call to a particular method and then later that method is overridden, it can just re-bind it again.

[neilcoffey]

P.S. I say "just" re-bind -- obviously there's a little bit of complexity involved. But Hotspot at least does have the complexity to detect when it needs to do things like switch back from compiled to interpreted methods and do re-binding.

[neilcoffey]

P.P.S. When I say "method", the same applies for final classes too. There's no performance gain in declaring a class final -- the VM knows whether you've subclassed it or not!

[Jary316]

So if I understand, final methods can be bound after compilation, during run time.

Static methods and overloaded methods are bound during compilation (or early binding).

Is that correct?

[neilcoffey]

I don't think there's any special treatment given to static vs non-static or final vs non-final methods or overridden vs non-overridden (I assume you mean this, not "overloaded" -- but again, to the JVM, an overloaded method is nothing special either).

Remember that at runtime, all method calls are essentially looked up by object, method name and method signature at the moment of calling the method. So given a particular object and method name/signature, the JVM looks up its class definition, then does a "top down" search, starting at the lowest subclass and working its way up the chain of superclasses until it finds a matching method. Obviously, it may optimise or cache that lookup in all sorts of ways, but behaviourally this is what it does according to the language specification.