Compiler generated methods

Brian Goetz brian.goetz at oracle.com
Sat May 15 18:10:48 PDT 2010


> (Brian Goetz has also sighted simplifying tooling as a motivation for
> compiler generated methods, I don't see this since the tooling still
> has to cope with classloader generated methods.)

The argument for the compiler+VM approach is a practical one aimed at risk 
mitigation, not elimination.

With a VM-only approach, we are making a permanent change in a classfile 
invariant, which is likely to eventually require all tools to change.  That 
has a real cost, and one which I will not impose lightly.

By adding in compiler behavior, the only files that will be potentially 
confusing to tools will be pre-7.0 classfiles that implement extended 
interfaces and do not extend skeletal implementations (like AbstractSet) that 
provide implementations.  And, in the event that this is a problem for 
tooling, and the tool vendor has not updated the tool (or the user has not 
paid for the upgrade), there's a workaround *that is under the control of the 
user, not the tool vendor*: recompile the class (or, equivalently, 
post-process the class with a weaving tool that will have the same effect). 
In no case are the users left high and dry with "old" tools.

Over time, the set of old+moldy class files which meet the narrow criteria 
above will approach zero, at which point we re-enter the world where "old" 
tools just work without any workaround needed by the user.  So it is quite 
possible that with a compiler+VM strategy, many third-party tools need not 
change at all.  This is a tradeoff whereby we make some extra work for 
ourselves, but potentially alleviate pressure on the tools vendors.



More information about the lambda-dev mailing list