Compiler generated methods

Mikael Grev grev at
Sun May 16 00:17:40 PDT 2010

I think that tools not being updated is not the best reason for choosing
one implementation over the other. By requiring updates you also introduce
an advantage for updated tools. A tool that is actively updated should
always have an advantage against one that isn't. By choosing a sub par
approach just to deny competition is in my opinion thinking backwards.

As long as the reason for changing something is sound one should do so.
Otherwise the market grows stale and hinders innovation and progress.


On May 16, 2010, at 3:10 AM, Brian Goetz wrote:

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