Call for Discussion: New Project: Leyden

[mark.reinhold at oracle.com]

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

- Mark


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