Call for Discussion: New Project: Leyden

[Volker Simonis]

On Thu, Apr 30, 2020 at 6:55 PM <mark.reinhold at oracle.com> wrote:
>
> 2020/4/29 7:13:37 -0700, volker.simonis at gmail.com:
> > 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:
> >>> 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).
>
> The former (i.e., (a)).
>
> > If the answer is a), will they be an optional or mandatory part of the
> > new Java SE specification?
>
> Optional, most likely.
>
> > 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?
>
> The notion of “subset” is tricky in this context.  I expect that most,
> if not all, of the Java API will be available to applications that run
> as static images.  When used in a static image, however, some APIs will
> be specified to behave differently, principally by throwing exceptions
> in situations that cannot be supported in static mode.  Invoking
> `Class.forName("p.Q")` for a class `p.Q` that doesn’t exist in the image
> would, e.g., throw a `ClassNotFoundException`, or perhaps a new subclass
> of that exception, `ClassNotFoundInStaticImageException`.
>
> The goal is to have all of the functionality required to make good use
> of static images be part of the Java Platform Specification.  There will
> no doubt be room for implementation-specific extensions, as is the case
> with other facilities in the Platform, and over time such extensions may
> motivate further enhancements to 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.
>
> Not true.  Since Java 9, the Platform Specification has explicitly
> defined what it means to have a compatible subset of the entire set
> of standard modules [1].
>

You're right. I somehow forgot about that although now, after reading
it I'm pretty sure I didn't read it for the first time :)

Thanks,
Volker

> - Mark
>
>
> [1] https://cr.openjdk.java.net/~iris/se/9/java-se-9-fr-spec/#Constraints-on-all-modules-in-an-Implementation