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

[Anderson Vasconcelos Pires]

Hi Volker,

Looks like the graal uses the similar license of openjdk.
I understand they would have the same limitation to generate native images,
right?
If I am not wrong, why do they decide to have native image? We couldn't use
at least the same approach?

Best regards,
Anderson.

On Sat, Apr 24, 2021 at 5:44 AM 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
> > >
> >
>