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

[Andrew Hughes]

----- Original Message -----
> 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.
> 

No.  This is not acceptable for a release branch.

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

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07