Virtual extension methods -- inaccuracy in strawman proposal?
Gernot Neppert
mcnepp02 at googlemail.com
Mon May 17 04:18:11 PDT 2010
Regarding Section 5 of the Strawman proposal:
"However, the VM may wish to load class files compiled by older
compilers, which under the current VM behavior would fail to load
because they do not implement all the methods of the interface they
claim to implement."
This is not the case!
*Classloading* does not fail if a class compiled against an older
version of an interface does not implement all methods.
Instead, trying to *invoke* such a method via the evolved interface
fails at runtime with an AbstractMethodError.
I think this is an important difference:
If your statement were true, it would mean that the VM would already
do the necessary checks during classloading.
Modifying the VM so that it auto-generates the missing methods would
not add huge additional overhead during classloading.
As it stands, however, those checks would have to be added to the
classloading sequence.
In particular, the VM would have to check during classloading:
- Is the class to be loaded (CTBL) abstract?
- If not, check all interfaces implemented by CTBL for the presence of
'extension methods'
- For every extension method, check whether the CTBL implements it,
either directly or via its baseclasses.
- For every non-implementd extension method, generate the code.
Note that these checks cannot be skipped, even if it turns out that
the CTBL does not need to be modified at all.
More information about the lambda-dev
mailing list