FYI: JamVM: JSR 335: Lambda Expressions; JSR 292: enable for OpenJDK 7/IcedTea 2; Updated to 2013-07-14 revision.

[Xerxes Rånby]

Robert Lougher have made stellar progress to enable stable JSR 335 and JSR 292 in JamVM.

I have pushed his JamVM work to IcedTea 1.x, 2.x and 3.x HEAD:
http://icedtea.classpath.org/hg/icedtea6/rev/e565715c45a7
http://icedtea.classpath.org/hg/icedtea7/rev/b5fa79fec364
http://icedtea.classpath.org/hg/icedtea/rev/8b48635893db

This update brings in two major highlights quoted below:
Thank you Robert for all the good work!
A back-port to the OpenJDK 7/IcedTea 2.4 release branch will follow.

Cheers
Xerxes



"JSR 292: enable for OpenJDK 7/IcedTea 2
IcedTea 2.4.0 is now based on OpenJDK update 40, which
contains the backport of JSR 292 from OpenJDK 8.

With a minor tweak (see previous checkins), JamVM's support
for JSR 292 with OpenJDK 8 works with IcedTea 2.4.0. As IcedTea
is the primary upstream client for JamVM/OpenJDK, this change
enables JSR 292 for OpenJDK 7 in addition to OpenJDK 8.

Signed-off-by: Robert Lougher <rob at jamvm.org.uk>"
http://git.berlios.de/cgi-bin/cgit.cgi/jamvm/commit/?id=1a58072f8339270f9372c273d82a00790e04375d



Proper JSR 335: Lambda Expressions
"JSR 335: handle multiple defaults and conflicts

With JSR 335, an interface can define default methods which
are used if a class which implements the interface does not
provide an implementation for that method.

While this is straight-forward to understand in the simple
case where a class ends up with a single default method, it
gets complicated when a class ends up with multiple defaults
from different interfaces.

A class implements not only its direct interfaces but also
the interfaces which its direct interfaces extends (recursively),
plus all the interfaces of its superclasses.

For a given unimplemented interface method there will potentially
be several definitions in the set of implemented interfaces -
some will be abstract and some will be defaults.

In that set, only the most specific are relevant, i.e. if
two interfaces define a default method foo, and B extends A,
then B's default takes precedence over A. If we end up with
only abstract most-specific methods, or a single most-specific
default things are OK. However, if we end up with multiple
defaults from unrelated interfaces we have a conflict.

JamVM previously handled unimplemented interface methods
(which before JSR 335 were all abstract) by creating Miranda
methods for them when constructing the interface method table
(if they were invoked, they threw an AbstractMethodError).

For JSR 335, this was extended to create Miranda methods for
unimplemented defaults - if they were invoked they executed
the default. This change modifies the code to also handle
multiple defaults and conflicting defaults. Previously, as
all methods were abstract, multiple definitions didn't matter.
Now, we need to ensure the correct default is chosen. This
is made more complex as a Miranda may be inherited from a
superclass. This Miranda may need to be overridden by an
additional Miranda in the subclass.

Note, if we have conflicting defaults an AbstractMethodError
is thrown. This copies HotSpot. However, the JSR 335 spec
states that an IncompatibleClassChangeError is thrown. I prefer
to follow HotSpot rather than the spec, but I will keep a lookout
in case HotSpot (or the spec) changes in the future...

Signed-off-by: Robert Lougher <rob at jamvm.org.uk>"
http://git.berlios.de/cgi-bin/cgit.cgi/jamvm/commit/?id=08e4b93b752f107eec983205c2225cef58b6ea7f