Call for Discussion: New Project: Leyden

[Volker Simonis]

On Tue, Apr 28, 2020 at 10:23 PM Kevin Regan <kevin.d.regan at gmail.com> wrote:
>
> I'm trying to think back over the years and I'm thinking most or all of the Java code that I've written would work in this static context. Could you provide real-world examples that wouldn't work?
>

If you have never used reflection, dynamic proxies, bytecode
generation or instrumentation, JVMTI, JMX etc. you might be right. But
remember that even if your code has never used these features, you
might have pulled them in through library dependencies even without
you being aware of them.

As I wrote before, the SubstrateVM project has a good overview [1] of
Java SE features which are not or only partially supported in a static
image. You can expect the new OpenJDK "static image" implementation to
have a similar set of restrictions.

[1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md

> On Tue, Apr 28, 2020 at 9:41 AM <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.)
>>
>> >                                                                 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.
>>
>> >> ...
>> >>
>> >> 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.
>>
>> - Mark