Compiler generated methods

Howard Lovatt howard.lovatt at gmail.com
Sat May 15 17:52:54 PDT 2010


The proposal for extension methods is very close to my Trait proposal:

http://www.artima.com/weblogs/viewpost.jsp?thread=220916

Including using a mixture of user, compiler, and VM generated methods.
There is no controversy around allowing users to override the new
methods in an interface; but there is a choice to made, is the
compiler allowed to add methods? My proposal like the strawman allowed
this, the reason I chose to do this was to reduce load time. The
disadvantage is that if the interface is changed but the class that
implements the interface isn't recompiled then the class will have the
old implementation. This is probably not the ideal behavior, since it
is most likely that the interface was upgraded to fix a bug.

Balancing these competing requirements I decided previously that
faster load time was the better trade off. This is a difficult choice;
perhaps best to go with the majority vote! Subsequently to publishing
my proposal 3 years ago I have changed my mind, I would now vote for
VM (classloader) only since the compiler optimizations have a poor
track record in Java (think String interning and static final
in-lining).

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

  -- Howard.


More information about the lambda-dev mailing list