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

[Mario Torre]

All,

Can we please go back to the merit of this discussion? Licensing terms
are a fun and an interesting topic, but not really one that should
distract us from the feedback that Andrew requested.

Cheers,
Mario

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


-- 
Mario Torre
Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898