Re: Binary Compatibility: vtable entries for final methods

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > "Removing the final modifier from a method does not break [binary
 > > compatibility.]"
 > > 
 > > So, our practice of making direct calls to final methods and not
 > > generating vtable entries for them must cease.  I'm minded to make an
 > > exception for java.lang.Object, because we'd otherwise add a bunch of
 > > vtable entries to every single class for no good reason.
 > 
 > Sorry for being a bit dense, but my reading of
 > JLS 13.4.15 and my understanding of a "binary compatible"
 > change does not let me see how your conclusion *necessarily*
 > follows.
 > 
 > Even with direct calls, after removing the "final" modifier,
 > a method can continue to be invoked as before without
 > exposing any change in *existing binaries*. I emphasise the
 > last part since that's the clientele that is being assured
 > by "binary compatibility" rules.

I'm assuming that when the author of a library removes `final' they
have a good reason for doing so.  One good reason is to override a
subclass method in order to fix a bug.  I'm also assuming that the
user of that library wants the bug fixed.

 > Now the JVM seems to use invokevirtual for "final" methods too
 > and therefore when you remove the "final" modifier, override
 > the method in a new sub-class and hand an object of this
 > new class to a client of the old class, it'll see the
 > effects of the overridden method but I don't see where
 > *this* is being guaranteed by the "binary compatibility"
 > rules.

Perhaps not, but I'm invoking the principle of least surprise here: if
we do anything different from other VMs we'll spend ages tracking down
bugs caused by the difference.

 > (In a way, I see this as *breaking* compatibility, but that's
 > another debate.)
 > 
 > The above happens as the JVM has no other way but invokevirtual
 > (yet) of "expressing" a call to a "final" method - but GCJ does
 > have the ability to express this for native executables
 > without breaking the specification for "binary compatibility".
 > 
 > I must say that your proposal does make GCJ behave like
 > the JVM, but this is not an area (IMHO) where we should
 > slavishly ape the JVM.

Why not?  I can see advantages in compatibility, but no disadvantages.
Except perhaps a slight growth in the size of vtables, I suppose.

Andrew.