Project Leyden: Beginnings

[Volker Simonis]

On Sat, May 28, 2022 at 6:47 PM Christian Wimmer
<christian.wimmer at oracle.com> wrote:
>
> Hi Andrew,
>
> Since you mentioned GraalVM: note that the GraalVM team at Oracle was
> advised to not talk about Native Image on this mailing list. Only when
> concrete questions arise, we will be happy to explain how things are
> handled in Native Image.
>

Sorry, but this seems really weird to me. With OpenJDK and GraalVM
Oracle is running two major open source projects and now Oracle
forbids its own employees working on one of the project to communicate
with the other ones? Is Oracle afraid of its own Terms of Use [1] or
am I missing something obvious? From my understanding, Oracle
employees working on the OpenJDK have started project Leyden to
introduce "a concept of _static images_ to the Java Platform" [2] and
"take inspiration from past efforts to explore this" like "the Native
Image feature of GraalVM" [2]. And then it took some other Oracle
employees another two years just to find out that they don't want its
first open source project to get too much inspired by the second one?

I'm puzzled...

[1] https://openjdk.java.net/legal/tou/terms
[2] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html

> -Christian
>
>
> On 5/27/22 06:33, Andrew Haley wrote:
> > On 5/20/22 15:42, mark.reinhold at oracle.com wrote:
> >
> > > Let us begin!
> >
> > As you'd expect, here at Red Hat there's a variety of opinions.
> > Rather than simply post my own response to this, I've been talking to
> > Middleware architects (the likely _users_ of Leyden!) as well as our
> > OpenJDK team members. Here's what we think:
> >
> >   We're excited to see Leyden taking shape and will be active
> >   participants. Our customers are benefiting from GraalVM today and as
> >   such we’ll continue to engage with that project as the Leyden ideas
> >   are explored and take shape.
> >
> >   Bringing standardization to this space is important for developers
> >   as it will clarify the behaviours they can depend on.  As we engage
> >   in updating the standard, we should consider not just new behavior,
> >   but also exceptions and variations that can accommodate some of the
> >   existing behavior of GraalVM such as build-time initialization.
> >
> >   The proposed incremental approach will ensure we bring along the
> >   current ecosystem and devtools while carefully introducing any new
> >   constraints. We also see the benefit in segmenting the problem space
> >   into discrete areas that can be introduced sooner rather than
> >   waiting for a big-bang integration of multiple constraints.
> >
> >   > In the long run we will likely embrace the full closed-world
> >   > constraint in order to produce fully-static images.
> >
> >   Our experience with Java on K8s and containers (notably Quarkus) has
> >   demonstrated real world benefits of a closed-world approach, so it's
> >   good to see it explicitly listed as a likely goal in the long
> >   run. It will be important that Leyden is careful to specify its
> >   efforts in the fast start / small footprint space while being
> >   mindful of that constraint.  Hopefully, we can all work towards a
> >   future that converges both GraalVM's efforts and those of Leyden.
> >