Compiler generated methods
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