Virtual extension methods -- a strawman design

Patrick Wright pdoubleya at
Sat May 15 07:56:20 PDT 2010

Hi Brian

I have comments on two sections:

4.3 Brittleness: offhand, it's difficult for me to say whether, if the
selection of a default method for an interface changes between two
releases, I would expect classes implementing the interface to
dispatch to the new or the old method. My gut feeling is it would be
less surprising if all classes I was loading and running used the new
method, even if this introduced behavioral changes (hopefully none, or
minor) into classes compiled against the original version of the
interface. I could see this argued both ways, but I don't like the
idea that two class files I was loading, both calling the same method
via an interface, would end up executing two different methods at
runtime for the same interface implementation. I would thus vote for a
dynamic (so to speak) dispatch to the current method selected by the

I imagine when the tools developers catch up they could issue warnings
about this happening by analyzing class files.

Although in principle in the projects I work on I have the sources
available to re-compile new JAR files, in practice what I see is that
once a JAR file is blessed, and there is no compelling reason to
rebuild it, that version of the JAR will be used going forward; this
is especially noticeable in the open-source software we use--we use
the end deliverable (JAR) and don't rebuild unless we have no other
choice. That makes me think this "brittleness" issue will be something
that we will have to keep in mind.

 5 Implementation: I'm a little concerned about the cost of
dynamically updating classes as they are loaded. Section 5.2 mentions
doing this with classloaders--I assume you mean standard JDK
classloaders, not a classloader implementation in the JVM itself?
Class loading time is already blamed in some circles for (relatively)
slow VM startup time; how can we avoid making this worse? I guess we
won't know if this is an issue until you can experiment with a
prototype implementation.


More information about the lambda-dev mailing list