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

[Robert Lougher]

On 14 August 2013 17:45, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- 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.
>>
>
> On further consideration, with 2.4.0 still tracking u40, we could update
> JamVM at this stage in the same manner.  What exactly are the changes needed
> here?
>

The head of JamVM is tracking OpenJDK 8.  This requires support for
Lambda expressions and the new JSR 292 implementation based on
LambdaForms.  The JSR 292 stuff has been backported to OpenJDK 7 but
without various bits for Lambda expressions (as OpenJDK 7 doesn't have
them).

The big change here is a configure change that enables JSR 292 when
the class-library is openjdk7 (it used to be enabled only when it was
openjdk8).  The bits of the implementation that are in fact related to
Lambda expressions have been guarded by JSR335, and are only built
when the class-library is openjdk8.  Some other changes for JSR335
which are not backwards compatible with OpenJDK 7 have also been
guarded.

Rob.

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