Virtual extension methods -- second draft

[Howard Lovatt]

*Brian Goetz* brian.goetz at oracle.com
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=lambda-dev%40openjdk.java.net&su=Virtual%20extension%20methods%20--%20second%20draft&In-Reply-To=4BEDD9E9.7050300%40oracle.com>
*Tue Jun 8 06:14:44 PDT 2010 wrote:*

**> I've updated the draft on Defender Methods:
>   http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf

Comments:

   1. Implementation option 2, section 8, seems to combine all the best
   characteristics; it doesn't unduly burden the class loader and
   is completely load-time and therefore the compiled code cannot become out of
   sync with interface modifications.
   2. I prefer the syntax option you list in Section 15:


"One alternative that was explored was to put the default method body right
into the

interface source file.  I think that this would be confusing for users; many
already don’t

quite get the difference between interfaces and abstract classes.  (This
would be more

appropriate if we went to full-blown traits.)"


I don't think that it would confuse people and would probably become the
norm, instead of abstract classes (which would be a good thing since it
would eliminate state). With the current proposal you have to make an
interface and a class of static methods, for *most* use cases this is
verbose and a pain since you separate the implementation from the
declaration. You can still forward to a static method when you want/need to
by calling the method directly from the body declared in the interface. Also
you don't need any new syntax constructs; just put the body in curly braces,
it will be most natural.


 -- Howard.