Call for Discussion: New Project: Leyden

[Volker Simonis]

On Tue, Apr 28, 2020 at 6:42 PM <mark.reinhold at oracle.com> wrote:
>
> 2020/4/27 13:05:06 -0700, volker.simonis at gmail.com:
> > On Mon, Apr 27, 2020 at 6:40 mark.reinhold at oracle.com wrote:
> >> ...
> >>
> >> Project Leyden will take inspiration from past efforts to explore this
> >> space, including the GNU Compiler for Java [1] and the Native Image
> >> feature of GraalVM [2].  Leyden will add static images to the Java
> >> Platform Specification, and we expect that GraalVM will evolve to
> >> implement that Specification.
> >
> > I think "adding static images" to the Java Platform Specification will
> > be the real tough part of this JEP. What are you envisioning here?
> > Something like the "compact profiles" [1] on Language/VM level?
>
> (I’m not sure what you mean by this.)

My question was if the "static images" features (and restrictions) will be:

 a) a part of the Java SE specification (e.g. like compact profiles)
 b) a separate platform specification (e.g. like Java ME).

If the answer is a), will they be an optional or mandatory part of the
new Java SE specification?

If they will be a part of the Java SE specification, will they be a
true subset of Java SE or do you expect that they may contain
extensions which will not be part of Java SE?

>
> >                                                                 Which
> > Java language/VM features are you ready to sacrifice for better
> > startup and lower footprint?
>
> Short, preliminary answer: Loading classes not known at build time, plus
> arbitrary uses of method handles and the `invokedynamic` bytecode.  (Uses
> of those features to, e.g., implement lambda expressions will work.)
>
> >                              GraalVM has its "small and well-guarded
> > secret" :) called "LIMITATIONS.md". Is this the set of limitations
> > you'd expect for the Java Platform Specification of static images as
> > well?
>
> I expect there to be some overlap, but it’s too early to say in detail.
>
> >       And finally, how do you plan to prevent the fragmentation of the
> > Java ecosystem into "full Java" and "static Java"?
>
> Recall the first constraint: A static image runs just one application,
> and no other.  A static image cannot run any code from outside the image,
> so there’s no risk that any particular image will somehow effectively
> define an alternate, non-standard version of the platform.
>
> It is true that the set of applications that can run in “static Java”
> will be a subset of those that require “full Java,” but then so is the
> set of applications that can run with just the `java.base` module vs.
> those that need more of the platform’s modules.

Yes, that's clear. But you can't currently create a "java.base" JDK
and pretend it to be "java.base" compatible. You can either claim Java
SE compatibility (in which case you'll have support the full Java
language specification, the full Java VM specification and everything
included in the "java.se" module) or no compatibility at all.

Everybody who is currently writing a Java application against the Java
SE specification can be sure that it will execute correctly on every
Java SE implementation.

As you mentioned, "static Java" won't be able to execute every Java SE
application any more. So we need a new "Java StaticEdition"
specification which people can develop against. We will get "Java
StaticEdition" compatible applications which will run on "Java SE" (if
"Java StaticEdition" will be a true subset of "Java SE"). But we might
also get "Java StaticEdition" implementations which won't be able to
run full "Java SE" applications.

>
> >> ...
> >>
> >> We do not intend to implement Leyden by merging the Native Image code
> >> from GraalVM into the JDK.  Leyden will, rather, be based upon existing
> >> components in the JDK such as the HotSpot JVM, the `jaotc` ahead-of-time
> >> compiler [3], application class-data sharing [4], and the `jlink` linking
> >> tool [5].
> >
> > While I personally like this approach and would very much welcome it
> > if it succeeds, I also think we have to be realistic. What makes you
> > believe that one JVM "can rule them all"?
> >
> > HotSpot's current runtime system and GCs are quite sophisticated and
> > complex. Adding one more use case (i.e. "native image") which they'll
> > have to support, will further increase the code complexity and long
> > term maintenance costs.
>
> I don’t expect that we’ll have to make significant changes to HotSpot
> in support of static images.  I’d be surprised if, e.g., the GCs will
> require any change at all.  The HotSpot that you get in a static image
> will, however, most likely be stripped down to omit features that are
> of less interest in static images.  (I’m sure we’ll have a thorough
> discussion of exactly what those features are at some point.)
>
> > I'm sincerely hoping that project "Leyden" is more than just an
> > instrument of one Oracle product team fighting against another one and
> > wish that the OpenJDK and the GraalVM teams could join forces for the
> > advance and benefit of the Java platform as a whole.
>
> This is absolutely not about “one Oracle product team fighting against
> another one.”  The two teams will work together on this effort, hopefully
> with additional contributions from non-Oracle developers.  I fully expect
> regular participation from Christian Wimmer, Thomas Wuerthinger, Vojin
> Jovanovic, and other members of the GraalVM team.
>

Thanks for the clarification. That sounds very promising.

> - Mark