Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden)

Sat Apr 24 15:03:59 UTC 2021

Mario Torre <neugens.limasoftware at gmail.com> schrieb am Sa., 24. Apr. 2021,
12:07:

> Hi Volker,
>
> This is certainly a conversation we need to have, however one of most
> important reasons for project Leyden is to understand and define a
> specification that works properly under the closed world-aot assumption.
>
> I think there is tremendous value in doing so within the OpenJDK umbrella
> with hotspot as reference implementation, depending on external or
> downstream projects would limit the scope considerably and may not work at
> all.
>

Sure, I totally agree with everything you say. But implementing a reference
implementation which will only usable by/with GPLv2 licensed applications
will limit the scope even more.

> Cheers,
> Mario
>
> —
> Mario Torre
> Java Champion and OpenJDK contributor
>
> PGP Key: 0BAB254E
> Fingerprint: AB1C 7C6F 7181 895F E581  93A9 C6B8 A242 0BAB 254E
>
> Twitter: @neugens
> Web: https://www.mario-torre.eu/
> Music: https://mario-torre.bandcamp.com/
>
>
> On Saturday, Apr 24, 2021 at 11:29, Volker Simonis <
> volker.simonis at gmail.com> wrote:
> Hi Andrew,
>
> thank you so much for resurrecting the discussion on project Leyden! I
> read through your leydendoc [1] which I think is an excellent and
> technically deep-dive summary of the current workings of the GraalVM
> Native Image Generator. The analysis and ideas how this functionality
> could be implemented in the context of OpenJDK and HotSpot is
> technically sound and very interesting.
>
> I'm really a little reluctant to add some non-technical doubts and
> acting as a killjoy here, but I think there's one real caveat with
> your approach and that's (unfortunately) licensing. As you know, the
> whole HotSpot code base (with the exception of very few header files
> [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE).
> HotSpot code can only be accessed without getting tainted by the GPL
> through a restricted set of exported, GPLv2+CPE licensed interfaces
> [2]. This is already a "weak" construct which has never been disputed
> but I don't want to discuss that here.
>
> I'm however afraid that your approach of linking large parts of the
> HotSpot code together with application classes into a single static
> image will undoubtedly "infect" all the user code with the GPL
> license. I think that's unacceptable for the majority of Java
> applications which are not already GPLv2 licensed. Unfortunately, in
> my opinion this seems to be a much bigger problem compared to the
> technical difficulties to implement your approach. Maybe we should
> have a look at alternative, existing JVM implementations (like OpenJ9,
> which I'm not all all familiar with) which are more liberally
> licensed? Having another write-up, similar to yours, which explores
> the same possibilities with OpenJ9 would be definitely a nice read :)
>
> As a side note, it seems like all the Java classes and even the native
> code parts of the class library are all licensed under GPLv2+CPE. So
> linking them into a native image together with user/application code
> seems to be less of a problem.
>
> Thanks again for your great analysis,
> Volker
>
> [1] https://github.com/adinn/leydendoc
> [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl
>
> On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn <adinn at redhat.com> wrote:
>
>
> Hello All,
>
> There has been a rather long and quiet interlude since the result of the
> Leyden vote was reported (see below). Unfortunately, there has not yet
> been any follow-up announcement of a project repo, mail list(s) or
> working group. However, that's no indication that the project is not
> still of great interest to those of us who voted for it, nor that some
> of us have not been thinking about how we might proceed.
>
> I'd like to resume the initial discussion and, I hope, trigger some
> follow-up actions by offering a few recommendations for how we might
> wish to progress with Leyden. This is based on lessons learned from
> working with the GraalVM Native implementation over the last year or two.
>
> Please note that I'm not suggesting that GraalVM Native provides a
> blueprint for how Leyden should proceed. Indeed, I recognise that one of
> the key reasons for creating the Leyden project is to sharpen up the
> definition of static Java and, in doing so, critique some of the choices
> made in implementing GraalVM Native.
>
> The path I am proposing we follow here is to:
>
> - identify some of the key architectural and design decisions made in
> implementing GraalVM Native that appear to be relevant to a Hotspot
> implementation
>
> - gauge how far those decisions contribute to improvements in certain
> aspects of GraalVM Native performance vs degradation in other aspects
>
> - at the same time assess how systematically and coherently those same
> decisions deal, or fail to deal, with some of the problematic semantic
> issues involved in delivering static Java deployments
>
> - consider whether similar decisions might be worth taking in the
> context of an implementation based on the current Hotspot code base
>
> I have posted a document to github [1] that provides a summary of my own
> thoughts on the above themes. It starts with a critique of GraalVM
> which, for the benefit of OpenJDK project members who are not familiar
> with the implementation, also explains (as accurately as my
> understanding permits) relevant aspects of the design and
> implementation. It then goes on to discuss how this might be relevant to
> a Leyden implementation that reuses existing Hotspot components as far
> as possible.
>
> The document has been reviewed informally by a few OpenJDK project
> colleagues. I'd be very grateful if others who have expressed an
> interest in the project could take the time to read it and reflect on
> it, either providing feedback directly on the document or following up
> with their own opinions and suggestions for how to proceed.
>
> [1] https://github.com/adinn/leydendoc
> n.b. the repo has a Creative Commons 1.0 open source license.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>
>
>
> On 11/06/2020 17:36, mark.reinhold at oracle.com wrote:
>
> Voting on the Leyden Project [1], with me as the initial Lead,
> is now closed.
>
> Yes: 38
> Veto: 0
> Abstain: 0
>
> (Two votes, by individuals not in the Members Group [2], did
> not count.)
>
> According to the Bylaws definition of Lazy Consensus, this is
> sufficient to approve the new Project and its initial Lead.
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html
> [2] https://openjdk.java.net/census#members
>
>
>