Re: Binary Compatibility: vtable entries for final methods

[Ranjit Mathew <rmathew at gmail dot com>]

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.

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. (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.

My 2p.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/