From rfscholte at apache.org  Sat Jul  8 16:59:54 2017
From: rfscholte at apache.org (Robert Scholte)
Date: Sat, 08 Jul 2017 18:59:54 +0200
Subject: Runtime.Version
Message-ID: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>

Hi,

I'm kind of surprised by the number of methods of Runtime.Version:
http://download.java.net/java/jigsaw/docs/api/java/lang/Runtime.Version.html

Based on my experience with versions I would advice to reduce the number  
of methods.

With Maven we had this interface:
http://maven.apache.org/ref/3.5.0/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ArtifactVersion.html

However, in the end all those separate segments didn't add a thing and are  
actually causing unnecessary complex code in case we were doing other  
implementations with ArtifactVersion. ArtifactVersion is quite an  
important interface in our code, so there's no simple solution to simplify  
this mistake.

I'm really pleased that for Aether (which is now back at Maven as Artifact  
Resolver) it is all reduced to this:
http://maven.apache.org/resolver/apidocs/org/eclipse/aether/version/Version.html

This is all we need: parsing + comparing (+ #toString()). If none of the  
additional methods of Runtime.Version is used *yet*, you should consider  
to remove them.

thanks,
Robert

From forax at univ-mlv.fr  Sat Jul  8 17:44:11 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 8 Jul 2017 19:44:11 +0200 (CEST)
Subject: Runtime.Version
In-Reply-To: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
References: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
Message-ID: <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>

Hi Robert,
this is the JDK version as specified by JEP 223 [1], this is not an artifact version, this is the JDK (as a whole) version.

The ModuleDescriptor.Version [2] is the module version, something like your artifact version.

The JDK version is loosely related to a module version because they some version components like starting with 9.

That's said, i'm not sure the JDK version is something that should be checked/compared in the code, after all people can build there own JDK with their own version.
You can use the java.base version instead, there is a signing mechanism (the module hashes) that ensures that the jdk modules and the java.base module are compatible.

regards,
R?mi

[1] [1] http://openjdk.java.net/jeps/223
[2] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleDescriptor.Version.html

----- Mail original -----
> De: "Robert Scholte" <rfscholte at apache.org>
> ?: jpms-spec-experts at openjdk.java.net
> Envoy?: Samedi 8 Juillet 2017 18:59:54
> Objet: Runtime.Version

> Hi,
> 
> I'm kind of surprised by the number of methods of Runtime.Version:
> http://download.java.net/java/jigsaw/docs/api/java/lang/Runtime.Version.html
> 
> Based on my experience with versions I would advice to reduce the number
> of methods.
> 
> With Maven we had this interface:
> http://maven.apache.org/ref/3.5.0/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ArtifactVersion.html
> 
> However, in the end all those separate segments didn't add a thing and are
> actually causing unnecessary complex code in case we were doing other
> implementations with ArtifactVersion. ArtifactVersion is quite an
> important interface in our code, so there's no simple solution to simplify
> this mistake.
> 
> I'm really pleased that for Aether (which is now back at Maven as Artifact
> Resolver) it is all reduced to this:
> http://maven.apache.org/resolver/apidocs/org/eclipse/aether/version/Version.html
> 
> This is all we need: parsing + comparing (+ #toString()). If none of the
> additional methods of Runtime.Version is used *yet*, you should consider
> to remove them.
> 
> thanks,
> Robert

From rfscholte at apache.org  Sat Jul  8 18:11:17 2017
From: rfscholte at apache.org (Robert Scholte)
Date: Sat, 08 Jul 2017 20:11:17 +0200
Subject: Runtime.Version
In-Reply-To: <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
References: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
 <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
Message-ID: <op.y22ks3jqkdkhrr@desktop-2khsk44.dynamic.ziggo.nl>

Hi R?mi,

I'm talking about the concept of Versions in general, adding some examples.
Right now I'm working on the maven-javadoc-plugin which has a parsing  
issue since b175, which is more in line with Runtime.Version. In the  
future the plugin could switch to Runtime.Version, that why I had a look  
this new class.

Providing getters for all parts of the version-string could block future  
changes of the version scheme.

thanks,
Robert

On Sat, 08 Jul 2017 19:44:11 +0200, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Robert,
> this is the JDK version as specified by JEP 223 [1], this is not an  
> artifact version, this is the JDK (as a whole) version.
>
> The ModuleDescriptor.Version [2] is the module version, something like  
> your artifact version.
>
> The JDK version is loosely related to a module version because they some  
> version components like starting with 9.
>
> That's said, i'm not sure the JDK version is something that should be  
> checked/compared in the code, after all people can build there own JDK  
> with their own version.
> You can use the java.base version instead, there is a signing mechanism  
> (the module hashes) that ensures that the jdk modules and the java.base  
> module are compatible.
>
> regards,
> R?mi
>
> [1] [1] http://openjdk.java.net/jeps/223
> [2]  
> http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleDescriptor.Version.html
>
> ----- Mail original -----
>> De: "Robert Scholte" <rfscholte at apache.org>
>> ?: jpms-spec-experts at openjdk.java.net
>> Envoy?: Samedi 8 Juillet 2017 18:59:54
>> Objet: Runtime.Version
>
>> Hi,
>>
>> I'm kind of surprised by the number of methods of Runtime.Version:
>> http://download.java.net/java/jigsaw/docs/api/java/lang/Runtime.Version.html
>>
>> Based on my experience with versions I would advice to reduce the number
>> of methods.
>>
>> With Maven we had this interface:
>> http://maven.apache.org/ref/3.5.0/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ArtifactVersion.html
>>
>> However, in the end all those separate segments didn't add a thing and  
>> are
>> actually causing unnecessary complex code in case we were doing other
>> implementations with ArtifactVersion. ArtifactVersion is quite an
>> important interface in our code, so there's no simple solution to  
>> simplify
>> this mistake.
>>
>> I'm really pleased that for Aether (which is now back at Maven as  
>> Artifact
>> Resolver) it is all reduced to this:
>> http://maven.apache.org/resolver/apidocs/org/eclipse/aether/version/Version.html
>>
>> This is all we need: parsing + comparing (+ #toString()). If none of the
>> additional methods of Runtime.Version is used *yet*, you should consider
>> to remove them.
>>
>> thanks,
>> Robert

From mark.reinhold at oracle.com  Tue Jul 11 17:10:38 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Jul 2017 10:10:38 -0700 (PDT)
Subject: Updated conformance text for Java SE 9 (JSR 379)
Message-ID: <20170711171038.F369C81DEC@eggemoggin.niobe.net>

Attached below is revised and expanded text for the "Conformance"
subsection of the "Modular platform" section [1] of the Java SE 9
(JSR 379) specification.  This text straddles both the JPMS and
Java SE 9 JSRs.  To keep all of the conformance language in one
convenient place I propose to include it only in the Java SE 9
specification.

This version clarifies some details in the previous version [2] and,
further, specifies the manner in which the strong encapsulation of
modules may be relaxed.

Comments welcome.

- Mark

[1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec/#s7
[2] http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2017-May/000020.html

----

Every Implementation of this Specification must include the `java.base`
module, _i.e._, must make that module observable.  An Implementation may,
further, include one or more additional Java SE modules so long as the
set of Java SE modules that the Implementation includes is _closed_,
i.e., contains every Java SE module required, via `requires transitive`
directives, by any member of the set.  For a specific example, an
Implementation that contains just the `java.base`, `java.sql`,
`java.logging`, and `java.xml` modules is closed because the only
`requires transitive` dependences are from `java.sql` to `java.logging`
and `java.xml`, and the latter two modules are members of the set.

The Technology Compatibility Kit (TCK) for this Specification will be
able to test all of the Java SE modules included in an Implementation,
and it will require that set to be closed.  An Implementation that passes
the TCK is considered to fully implement this Specification even if it
does not include all of the Java SE modules.

If an Implementation of this Specification includes a Java SE module then
it must fully implement the corresponding part of this Specification.  It
must, in particular, implement every API element of that module including
the module???s name, its exported packages, and any `requires transitive`
dependences.  It must not export any of that module???s other packages
without qualification.

This Specification defines the Licensor Name Space on a module-by-module
basis.  Provided that an Implementation that fully implements this
Specification includes the required Licensor Name Space for each included
module then it is not considered to subset the Licensor Name Space.

An Implementation of this Specification may provide a means to create
further Implementations.  If it does so then any new Implementation must
satisfy the constraints of the preceding paragraphs but need not include
all of the modules present in the original Implementation.

As an aid to migration, an Implementation may relax the strong
encapsulation of the modules that it includes as follows:

  - An Implementation may provide a means to invoke its run-time system
    with one or more packages of one or more of its modules open to code
    in all unnamed modules, i.e., to code on the class path.  The first
    access to an element of such a package by a program via a reflection
    API must cause a warning to be issued on the standard error stream.
    Later accesses may also cause warnings to be issued.

  - An Implementation may, by default, open one or more packages of one
    or more of its modules to code in all unnamed modules.  If it does so
    then it must issue warnings as described in the previous paragraph.
    If it does so then it must, further, provide a means to invoke its
    run-time system without opening any packages of any of its modules.

    (The Reference Implementation's run-time system behaves this way by
     default, and because this is the default it can also be invoked
     without opening any of its packages via the command-line option
     `--illegal-access=deny`.)

  - An Implementation may provide a means to request that additional
    warnings or debugging information, such as stack traces, be issued
    when elements of its open packages are accessed via a reflection API.

    (The Reference Implementation's run-time system can be invoked with
     the command-line options `--illegal-access=warn` or
     `--illegal-access=debug` in order to request warnings or both
     warnings and stack traces, respectively, on each unique reflective
     access to any open Implementation package.)

Future revisions of this Specification are expected to mandate that all
of an Implementation's modules be strongly encapsulated by default and,
eventually, to disallow the above-described relaxation.

As a further aid to migration, an Implementation may provide a means to
invoke its run-time system in a way that establishes additional
relationships between specific modules, identified by name, regardless of
the original declarations of those modules and regardless of whether
those modules are included in the Implementation or are part of the
application being run:

  - One module can be made to read another module.

    (The Reference Implementation provides this capability via the
     `--add-reads` command-line option.)

  - A package of one module can be opened to another module.

    (The Reference Implementation provides this capability via the
     `--add-opens` command-line option.)

  - A package of one module can be exported to another module.

    (The Reference Implementation provides this capability via the
     `--add-exports` command-line option.)

  - A package of one module can be opened or exported to every unnamed
    module.

    (The Reference Implementation provides this capability by allowing
     the special token `ALL-UNNAMED` to be used as a target of the
     `--add-opens` and `--add-exports` command-line options.)

None of these capabilities, for any modules, may be operative by default.
A future revision of this Specification may disallow these capabilities.

From mark.reinhold at oracle.com  Tue Jul 11 17:27:02 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Jul 2017 10:27:02 -0700
Subject: Runtime.Version
In-Reply-To: <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
References: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
 <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
Message-ID: <20170711102702.919424762@eggemoggin.niobe.net>

2017/7/8 10:44:11 -0700, Remi Forax <forax at univ-mlv.fr>:
> this is the JDK version as specified by JEP 223 [1], this is not an
> artifact version, this is the JDK (as a whole) version.

Correct.

> The ModuleDescriptor.Version [2] is the module version, something like
> your artifact version.

Right, and it's more abstract than `Runtime.Version` for exactly the
reasons that Robert mentioned.

> The JDK version is loosely related to a module version because they
> some version components like starting with 9.
> 
> That's said, i'm not sure the JDK version is something that should be
> checked/compared in the code, after all people can build there own JDK
> with their own version.

You'd have to hack the JDK build system pretty heavily in order to use
a version string that's not parseable as a `Runtime.Version`.  I'm not
sure why anyone would do that.

>                          You can use the java.base version instead,
> there is a signing mechanism (the module hashes) that ensures that the
> jdk modules and the java.base module are compatible.

The build system ensures that the version strings of all modules, and of
the JDK itself, are the same even though module versions are represented
as instances of `ModuleDescriptor.Version` and the platform version is
represented as a `Runtime.Version`.

- Mark

From rfscholte at apache.org  Tue Jul 18 20:12:23 2017
From: rfscholte at apache.org (Robert Scholte)
Date: Tue, 18 Jul 2017 22:12:23 +0200
Subject: Runtime.Version
In-Reply-To: <20170711102702.919424762@eggemoggin.niobe.net>
References: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
 <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
 <20170711102702.919424762@eggemoggin.niobe.net>
Message-ID: <op.y3k82xf6kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>

For several plugins we need to compare the Java version. That's not always  
the Runtime used by Maven, but another (often older) installed JRE/JDK,  
e.g. by calling javadoc -J-version or java -version and parsing its output.
If would help us if we could implement our own parsing strategy and get a  
Runtime.Version for comparison. All currently exposed segments won't help  
here and as said I wonder where these are actually used apart from the  
compareTo-method.
Otherwise we're reinventing/reimplementing the comparison algorithm of  
JEP223 too.

thanks,
Robert

On Tue, 11 Jul 2017 19:27:02 +0200, <mark.reinhold at oracle.com> wrote:

> 2017/7/8 10:44:11 -0700, Remi Forax <forax at univ-mlv.fr>:
>> this is the JDK version as specified by JEP 223 [1], this is not an
>> artifact version, this is the JDK (as a whole) version.
>
> Correct.
>
>> The ModuleDescriptor.Version [2] is the module version, something like
>> your artifact version.
>
> Right, and it's more abstract than `Runtime.Version` for exactly the
> reasons that Robert mentioned.
>
>> The JDK version is loosely related to a module version because they
>> some version components like starting with 9.
>>
>> That's said, i'm not sure the JDK version is something that should be
>> checked/compared in the code, after all people can build there own JDK
>> with their own version.
>
> You'd have to hack the JDK build system pretty heavily in order to use
> a version string that's not parseable as a `Runtime.Version`.  I'm not
> sure why anyone would do that.
>
>>                          You can use the java.base version instead,
>> there is a signing mechanism (the module hashes) that ensures that the
>> jdk modules and the java.base module are compatible.
>
> The build system ensures that the version strings of all modules, and of
> the JDK itself, are the same even though module versions are represented
> as instances of `ModuleDescriptor.Version` and the platform version is
> represented as a `Runtime.Version`.
>
> - Mark

From mark.reinhold at oracle.com  Tue Jul 18 21:16:18 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 18 Jul 2017 14:16:18 -0700
Subject: Runtime.Version
In-Reply-To: <op.y3k82xf6kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
References: <op.y22hh4v4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
 <1001047046.3294735.1499535851807.JavaMail.zimbra@u-pem.fr>
 <20170711102702.919424762@eggemoggin.niobe.net>
 <op.y3k82xf6kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
Message-ID: <20170718141618.403250613@eggemoggin.niobe.net>

2017/7/18 13:12:23 -0700, rfscholte at apache.org:
> For several plugins we need to compare the Java version. That's not always  
> the Runtime used by Maven, but another (often older) installed JRE/JDK,  
> e.g. by calling javadoc -J-version or java -version and parsing its output.
> If would help us if we could implement our own parsing strategy and get a  
> Runtime.Version for comparison. All currently exposed segments won't help  
> here and as said I wonder where these are actually used apart from the  
> compareTo-method.
> Otherwise we're reinventing/reimplementing the comparison algorithm of  
> JEP223 too.

Sorry, but the `Runtime.Version` class was never intended to capture all
historical JDK version-numbering schemes, just the new scheme introduced
in Java SE 9.  If you want something more general then you'll have to
write it yourself.

- Mark

From Tim_Ellison at uk.ibm.com  Mon Jul 24 13:33:34 2017
From: Tim_Ellison at uk.ibm.com (Tim Ellison)
Date: Mon, 24 Jul 2017 14:33:34 +0100
Subject: Updated conformance text for Java SE 9 (JSR 379)
In-Reply-To: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
References: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
Message-ID: <OF0236EF82.B70113B8-ON80258167.00410865-80258167.004A7BC8@notes.na.collabserv.com>

Now that Java has introduced the concept of an explicit "link" stage for 
subsetting
the platform code, I think the conformance definition should differentiate 
between
an implementation of the specification that is providing a set of modules 
as open
APIs, and an implementation of the specification that is solely used to 
power a
"closed-world" application.

In the one case, a conformant platform may be a subset, and should provide 
a coherent
set of modules that implement a well-defined development/runtime platform. 
 In the other
case the implementation is being subset to provide a runtime fit for a 
particular
purpose.

With this in mind, we can introduce two new definitions:

A ?Platform Implementation? of this specification means a set of modules 
created to be
run with a variety of application programs, or linked with a specific 
application to
produce an ?Application Specific Implementation?, i.e. this is a library 
and associated
runtime.

An ?Application Specific Implementation? of this specification means a set 
of modules
that are linked to a specific application such that the modules are not 
observable at
runtime to code outside the application, i.e. this is a closed-world 
application.


The conformance description would then go on to refer to these as follows:

A Platform Implementation of this specification must include the 
`java.base`
module, _i.e._, must make that module observable.  A Platform 
Implementation may,
further, include one or more additional Java SE modules so long as the
set of Java SE modules that the Implementation includes is _closed_, ?

An Application Specific Implementation of this specification is not 
subject to the
same conformance requirements as a Platform Implementation of this 
specification.


Please see further specific comments in-lined below.

Regards,
Tim

mark.reinhold at oracle.com wrote on 11/07/2017 18:10:38:
> Attached below is revised and expanded text for the "Conformance"
> subsection of the "Modular platform" section [1] of the Java SE 9
> (JSR 379) specification.  This text straddles both the JPMS and
> Java SE 9 JSRs.  To keep all of the conformance language in one
> convenient place I propose to include it only in the Java SE 9
> specification.
> 
> This version clarifies some details in the previous version [2] and,
> further, specifies the manner in which the strong encapsulation of
> modules may be relaxed.
> 
> Comments welcome.
> 
> - Mark
> 
> [1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec/#s7
> [2] http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/
> 2017-May/000020.html
> 
> ----
> 
> Every Implementation of this Specification must include the `java.base`
> module, _i.e._, must make that module observable.  An Implementation 
may,
> further, include one or more additional Java SE modules so long as the
> set of Java SE modules that the Implementation includes is _closed_,
> i.e., contains every Java SE module required, via `requires transitive`
> directives, by any member of the set.  For a specific example, an
> Implementation that contains just the `java.base`, `java.sql`,
> `java.logging`, and `java.xml` modules is closed because the only
> `requires transitive` dependences are from `java.sql` to `java.logging`
> and `java.xml`,

and `java.base` if you are being transitive.

> and the latter two modules are members of the set.
> 
> The Technology Compatibility Kit (TCK) for this Specification will be
> able to test all of the Java SE modules included in an Implementation,

consider: strike out "be able to"

> and it will require that set to be closed.  An Implementation that 
passes
> the TCK is considered to fully implement this Specification even if it
> does not include all of the Java SE modules.

consider: "...TCK is considered to implement this Specification correctly 
even if..."
Saying it fully implements the spec with missing modules doesn't make 
sense.
 
> If an Implementation of this Specification includes a Java SE module 
then

How could an implementation of this specification *not* include an SE 
module?

> it must fully implement the corresponding part of this Specification. It
> must, in particular, implement every API element of that module 
including
> the module???s name, its exported packages, and any `requires 
transitive`
> dependences.  It must not export any of that module???s other packages
> without qualification.
> 
> This Specification defines the Licensor Name Space on a module-by-module
> basis.  Provided that an Implementation that fully implements this
> Specification includes the required Licensor Name Space for each 
included

consider: replace "required" by "entire"?

> module then it is not considered to subset the Licensor Name Space.

<snip>
> An Implementation of this Specification may provide a means to create
> further Implementations.  If it does so then any new Implementation must
> satisfy the constraints of the preceding paragraphs but need not include
> all of the modules present in the original Implementation.
</snip>

Why must it be an implementation of the specification that creates a 
further
implementation?  Maybe it is a builder tool, linker, stripper, etc.

> As an aid to migration, an Implementation may relax the strong
> encapsulation of the modules that it includes as follows:
> 
>   - An Implementation may provide a means to invoke its run-time system
>     with one or more packages of one or more of its modules open to code
>     in all unnamed modules, i.e., to code on the class path.

I suggest this should not be limited to invocation time, i.e. consider
replacing this sentence with:
    - An Implementation may provide a means to open one or more packages
      of one or more of its modules to code in all unnamed modules, i.e.,
      to code on the class path.

>     The first
>     access to an element of such a package by a program via a reflection
>     API must cause a warning to be issued on the standard error stream.
>     Later accesses may also cause warnings to be issued.

This should be an implementation choice, not a spec requirement.
It is not going to be possible to define a meaningful "warning", 
especially
in headless environments or places where the error console is not reified.

While I see the value in warnings at development time, requiring a warning
for every runtime invocation is unreasonable.

What will the JCK be checking to ensure this requirement is met?

>   - An Implementation may, by default, open one or more packages of one
>     or more of its modules to code in all unnamed modules.  If it does 
so
>     then it must issue warnings as described in the previous paragraph.

Consider: dropping this warnings requirement.

>     If it does so then it must, further, provide a means to invoke its
>     run-time system without opening any packages of any of its modules.
> 
>     (The Reference Implementation's run-time system behaves this way by
>      default, and because this is the default it can also be invoked
>      without opening any of its packages via the command-line option
>      `--illegal-access=deny`.)

<snip>
>   - An Implementation may provide a means to request that additional
>     warnings or debugging information, such as stack traces, be issued
>     when elements of its open packages are accessed via a reflection 
API.
> 
>     (The Reference Implementation's run-time system can be invoked with
>      the command-line options `--illegal-access=warn` or
>      `--illegal-access=debug` in order to request warnings or both
>      warnings and stack traces, respectively, on each unique reflective
>      access to any open Implementation package.)
</snip>

I suggest taking out the text between the <snip> markers.
This information is best provided in user docs rather than the conformance
definition, otherwise there will be a very long list of what /may/ be 
done.

> Future revisions of this Specification are expected to mandate that all
> of an Implementation's modules be strongly encapsulated by default and,
> eventually, to disallow the above-described relaxation.
> 
> As a further aid to migration, an Implementation may provide a means to
> invoke its run-time system in a way that establishes additional

Change to remove reference to invocation time, e.g. "...provide a means to
establish additional..."

> relationships between specific modules, identified by name, regardless 
of
> the original declarations of those modules and regardless of whether
> those modules are included in the Implementation or are part of the
> application being run:
> 
>   - One module can be made to read another module.
> 
>     (The Reference Implementation provides this capability via the
>      `--add-reads` command-line option.)
> 
>   - A package of one module can be opened to another module.
> 
>     (The Reference Implementation provides this capability via the
>      `--add-opens` command-line option.)
> 
>   - A package of one module can be exported to another module.
> 
>     (The Reference Implementation provides this capability via the
>      `--add-exports` command-line option.)
> 
>   - A package of one module can be opened or exported to every unnamed
>     module.
> 
>     (The Reference Implementation provides this capability by allowing
>      the special token `ALL-UNNAMED` to be used as a target of the
>      `--add-opens` and `--add-exports` command-line options.)
> 
> None of these capabilities, for any modules, may be operative by 
default.
> A future revision of this Specification may disallow these capabilities.
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From mark.reinhold at oracle.com  Mon Jul 24 22:51:52 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 24 Jul 2017 15:51:52 -0700
Subject: Updated conformance text for Java SE 9 (JSR 379)
In-Reply-To: <OF0236EF82.B70113B8-ON80258167.00410865-80258167.004A7BC8@notes.na.collabserv.com>
References: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
 <OF0236EF82.B70113B8-ON80258167.00410865-80258167.004A7BC8@notes.na.collabserv.com>
Message-ID: <20170724155152.708487470@eggemoggin.niobe.net>

// I posted the draft conformance text to both the 376 and 379 EG lists for
// maximal transparency.  Tim replied on the 376 list but his comments are
// equally relevant to 379, and 379 is where this text resides anyway.  I'm
// replying here to both EG lists.  Please be sure to include both lists in
// any further replies, and if needed I'll moderate them through on the
// list of which you're not a member.

2017/7/24 6:33:34 -0700, tim_ellison at uk.ibm.com:
> Now that Java has introduced the concept of an explicit "link" stage for
> subsetting the platform code, I think the conformance definition should
> differentiate between an implementation of the specification that is
> providing a set of modules as open APIs, and an implementation of the
> specification that is solely used to power a "closed-world" application.
> 
> In the one case, a conformant platform may be a subset, and should
> provide a coherent set of modules that implement a well-defined
> development/runtime platform.  In the other case the implementation is
> being subset to provide a runtime fit for a particular purpose.
> 
> With this in mind, we can introduce two new definitions:
> 
> A ?Platform Implementation? of this specification means a set of modules
> created to be run with a variety of application programs, or linked with
> a specific application to produce an ?Application Specific
> Implementation?, i.e. this is a library and associated runtime.
> 
> An ?Application Specific Implementation? of this specification means a
> set of modules that are linked to a specific application such that the
> modules are not observable at runtime to code outside the application,
> i.e. this is a closed-world application.

What does it mean for code to be "outside" an application?

What if the application loads additional modules from the module path,
or additional classes from the class path?  Is that code outside the
application?

What if the application loads user modules, or JAR files, or plugins, or
whatever, using its own custom class loader?  Is that code outside the
application?

Even without loading new external code, what if the application spins
bytecodes at run time?  Is that code outside the application?

In all of these situations the outside code will depend upon at least
some Java SE APIs.  To the extent that the modules that define those
APIs are present in the linked application image, people will sensibly
expect them to conform to the Platform Specification, and to pass the
TCK.

> The conformance description would then go on to refer to these as
> follows:
> 
> A Platform Implementation of this specification must include the
> `java.base` module, _i.e._, must make that module observable.  A Platform
> Implementation may, further, include one or more additional Java SE
> modules so long as the set of Java SE modules that the Implementation
> includes is _closed_, ?
> 
> An Application Specific Implementation of this specification is not
> subject to the same conformance requirements as a Platform Implementation
> of this specification.

The present Specification does not support "closed-world" applications.
There is no way to forbid the loading of additional classes at run time.
There is no way to make a set of modules unobservable to modules outside
of that set.  You can write code that simply avoids doing those things,
of course, but from the standpoint of the Platform Specification there
is no way to forbid those things from being done, and that's what you'd
need in order to guarantee a truly "closed world".

Perhaps a future revision will add those capabilities, but without them we
can't support a concept of "Application Specific Implementations".

> Please see further specific comments in-lined below.

My replies inline also.

> mark.reinhold at oracle.com wrote on 11/07/2017 18:10:38:
>> ...
>> 
>> Every Implementation of this Specification must include the `java.base`
>> module, _i.e._, must make that module observable.  An Implementation
>> may, further, include one or more additional Java SE modules so long as
>> the set of Java SE modules that the Implementation includes is _closed_,
>> i.e., contains every Java SE module required, via `requires transitive`
>> directives, by any member of the set.  For a specific example, an
>> Implementation that contains just the `java.base`, `java.sql`,
>> `java.logging`, and `java.xml` modules is closed because the only
>> `requires transitive` dependences are from `java.sql` to `java.logging`
>> and `java.xml`,
> 
> and `java.base` if you are being transitive.

No -- none of these modules `requires transitive java.base` since there
is no need for that, since every module implicitly `requires java.base`.

>> and the latter two modules are members of the set.
>> 
>> The Technology Compatibility Kit (TCK) for this Specification will be
>> able to test all of the Java SE modules included in an Implementation,
> 
> consider: strike out "be able to"

Done.

>> and it will require that set to be closed.  An Implementation that
>> passes the TCK is considered to fully implement this Specification even
>> if it does not include all of the Java SE modules.
> 
> consider: "...TCK is considered to implement this Specification correctly
> even if..."  Saying it fully implements the spec with missing modules
> doesn't make sense.

I understand that the use of "fully" here reads oddly, but it's needed
in order to be be consistent with the language of the Java Specification
Participation Agreement (JSPA [1]), and in particular with 5(B)a, which
enables independent Implementations.

>> If an Implementation of this Specification includes a Java SE module
>> then
> 
> How could an implementation of this specification *not* include an SE 
> module?

Yes, that's awkward; I've already fixed it in the next draft.

>> it must fully implement the corresponding part of this Specification. It
>> must, in particular, implement every API element of that module
>> including the module's name, its exported packages, and any `requires
>> transitive` dependences.  It must not export any of that module's other
>> packages without qualification.
>> 
>> This Specification defines the Licensor Name Space on a module-by-module
>> basis.  Provided that an Implementation that fully implements this
>> Specification includes the required Licensor Name Space for each
>> included
> 
> consider: replace "required" by "entire"?

Again, this is for consistency with the JSPA, in this case 5(B)b.

>> module then it is not considered to subset the Licensor Name Space.
> 
> <snip>
>> An Implementation of this Specification may provide a means to create
>> further Implementations.  If it does so then any new Implementation must
>> satisfy the constraints of the preceding paragraphs but need not include
>> all of the modules present in the original Implementation.
> </snip>
> 
> Why must it be an implementation of the specification that creates a
> further implementation?  Maybe it is a builder tool, linker, stripper,
> etc.

If it's a tool that's outside of an Implementation then there's no way
for this Specification to constrain it -- it's just an arbitrary tool.

>> As an aid to migration, an Implementation may relax the strong
>> encapsulation of the modules that it includes as follows:
>> 
>>  - An Implementation may provide a means to invoke its run-time system
>>    with one or more packages of one or more of its modules open to code
>>    in all unnamed modules, i.e., to code on the class path.
> 
> I suggest this should not be limited to invocation time, i.e. consider
> replacing this sentence with:
> 
>     - An Implementation may provide a means to open one or more packages
>       of one or more of its modules to code in all unnamed modules, i.e.,
>       to code on the class path.

That doesn't change the meaning of the statement, since opening a
package has no effect in any phase except run time.

>>    The first
>>    access to an element of such a package by a program via a reflection
>>    API must cause a warning to be issued on the standard error stream.
>>    Later accesses may also cause warnings to be issued.
> 
> This should be an implementation choice, not a spec requirement.  It
> is not going to be possible to define a meaningful "warning",
> especially in headless environments or places where the error console
> is not reified.

The "standard error stream" is perfectly meaningful (= `System.err`).
How it's logged or displayed is, of course, an implementation choice.

> While I see the value in warnings at development time, requiring a warning
> for every runtime invocation is unreasonable.

In light of the later statement that

  Future revisions of this Specification are expected to mandate that
  all of an Implementation's modules be strongly encapsulated by default
  and, eventually, to disallow the above-described relaxation.

it would be irresponsible in this version not to mandate some level of
warning.

> What will the JCK be checking to ensure this requirement is met?

The JCK will check the standard error stream.

>>  - An Implementation may, by default, open one or more packages of one
>>    or more of its modules to code in all unnamed modules.  If it does 
>>    so then it must issue warnings as described in the previous paragraph.
> 
> Consider: dropping this warnings requirement.

No, for the reasons previously stated.

>> ...
> 
> <snip>
>>  - An Implementation may provide a means to request that additional
>>    warnings or debugging information, such as stack traces, be issued
>>    when elements of its open packages are accessed via a reflection 
> API.
>> 
>>    (The Reference Implementation's run-time system can be invoked with
>>     the command-line options `--illegal-access=warn` or
>>     `--illegal-access=debug` in order to request warnings or both
>>     warnings and stack traces, respectively, on each unique reflective
>>     access to any open Implementation package.)
> </snip>
> 
> I suggest taking out the text between the <snip> markers.  This
> information is best provided in user docs rather than the conformance
> definition, otherwise there will be a very long list of what /may/ be
> done.

Good point -- done.

>> Future revisions of this Specification are expected to mandate that all
>> of an Implementation's modules be strongly encapsulated by default and,
>> eventually, to disallow the above-described relaxation.
>> 
>> As a further aid to migration, an Implementation may provide a means to
>> invoke its run-time system in a way that establishes additional
> 
> Change to remove reference to invocation time, e.g. "...provide a means to
> establish additional..."

Yes, though it's a bit more subtle than that -- adding reads edges and
exporting packages is relevant at both compile time and run time, but
opening packages is only relevant at run time.  Text corrected.

- Mark

From mark.reinhold at oracle.com  Tue Jul 25 02:16:04 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 24 Jul 2017 19:16:04 -0700 (PDT)
Subject: Draft JPMS Proposed Final Draft Specification
Message-ID: <20170725021604.1E13C980A7@eggemoggin.niobe.net>

I've posted a draft Proposed Final Draft Specification to the usual URL:

    http://cr.openjdk.java.net/~mr/jigsaw/spec/

The only significant change relative to the most recent working draft,
which I posted on 27 June, is that the JVMS draft was updated to clarify
when a class file defines a module as opposed to a class or an interface.

I plan to submit this to the JCP as the Proposed Final Draft next week.
Please let me know by 23:59 UTC next Monday, 31 July, if you think any
changes are required.

- Mark

From volker.simonis at gmail.com  Tue Jul 25 18:15:57 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 25 Jul 2017 20:15:57 +0200
Subject: Updated conformance text for Java SE 9 (JSR 379)
In-Reply-To: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
References: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
Message-ID: <CA+3eh12CyrrLrmNyAXpg7ErT9X3Ef3s+wOjpSvVA7Rmx04bxaQ@mail.gmail.com>

On Tue, Jul 11, 2017 at 7:10 PM,  <mark.reinhold at oracle.com> wrote:
> Attached below is revised and expanded text for the "Conformance"
> subsection of the "Modular platform" section [1] of the Java SE 9
> (JSR 379) specification.  This text straddles both the JPMS and
> Java SE 9 JSRs.  To keep all of the conformance language in one
> convenient place I propose to include it only in the Java SE 9
> specification.
>
> This version clarifies some details in the previous version [2] and,
> further, specifies the manner in which the strong encapsulation of
> modules may be relaxed.
>
> Comments welcome.
>
> - Mark
>
> [1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec/#s7
> [2] http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2017-May/000020.html
>
> ----
>
> Every Implementation of this Specification must include the `java.base`
> module, _i.e._, must make that module observable.  An Implementation may,
> further, include one or more additional Java SE modules so long as the
> set of Java SE modules that the Implementation includes is _closed_,
> i.e., contains every Java SE module required, via `requires transitive`
> directives, by any member of the set.  For a specific example, an
> Implementation that contains just the `java.base`, `java.sql`,
> `java.logging`, and `java.xml` modules is closed because the only
> `requires transitive` dependences are from `java.sql` to `java.logging`
> and `java.xml`, and the latter two modules are members of the set.
>
> The Technology Compatibility Kit (TCK) for this Specification will be
> able to test all of the Java SE modules included in an Implementation,
> and it will require that set to be closed.  An Implementation that passes
> the TCK is considered to fully implement this Specification even if it
> does not include all of the Java SE modules.
>
> If an Implementation of this Specification includes a Java SE module then
> it must fully implement the corresponding part of this Specification.  It
> must, in particular, implement every API element of that module including
> the module?s name, its exported packages, and any `requires transitive`
> dependences.  It must not export any of that module?s other packages
> without qualification.
>
> This Specification defines the Licensor Name Space on a module-by-module
> basis.  Provided that an Implementation that fully implements this
> Specification includes the required Licensor Name Space for each included
> module then it is not considered to subset the Licensor Name Space.
>
> An Implementation of this Specification may provide a means to create
> further Implementations.  If it does so then any new Implementation must
> satisfy the constraints of the preceding paragraphs but need not include
> all of the modules present in the original Implementation.
>
> As an aid to migration, an Implementation may relax the strong
> encapsulation of the modules that it includes as follows:
>
>   - An Implementation may provide a means to invoke its run-time system
>     with one or more packages of one or more of its modules open to code
>     in all unnamed modules, i.e., to code on the class path.  The first
>     access to an element of such a package by a program via a reflection
>     API must cause a warning to be issued on the standard error stream.
>     Later accesses may also cause warnings to be issued.
>
>   - An Implementation may, by default, open one or more packages of one
>     or more of its modules to code in all unnamed modules.  If it does so
>     then it must issue warnings as described in the previous paragraph.
>     If it does so then it must, further, provide a means to invoke its
>     run-time system without opening any packages of any of its modules.
>
>     (The Reference Implementation's run-time system behaves this way by
>      default, and because this is the default it can also be invoked
>      without opening any of its packages via the command-line option
>      `--illegal-access=deny`.)
>

This is still not totally clear to me. Does it mean the specification
requires at least one warning for each package where we have an
illegal access, for each module where we have an illegal access or is
one single warning per invocation of the VM enough?

>   - An Implementation may provide a means to request that additional
>     warnings or debugging information, such as stack traces, be issued
>     when elements of its open packages are accessed via a reflection API.
>
>     (The Reference Implementation's run-time system can be invoked with
>      the command-line options `--illegal-access=warn` or
>      `--illegal-access=debug` in order to request warnings or both
>      warnings and stack traces, respectively, on each unique reflective
>      access to any open Implementation package.)
>
> Future revisions of this Specification are expected to mandate that all
> of an Implementation's modules be strongly encapsulated by default and,
> eventually, to disallow the above-described relaxation.
>
> As a further aid to migration, an Implementation may provide a means to
> invoke its run-time system in a way that establishes additional
> relationships between specific modules, identified by name, regardless of
> the original declarations of those modules and regardless of whether
> those modules are included in the Implementation or are part of the
> application being run:
>
>   - One module can be made to read another module.
>
>     (The Reference Implementation provides this capability via the
>      `--add-reads` command-line option.)
>
>   - A package of one module can be opened to another module.
>
>     (The Reference Implementation provides this capability via the
>      `--add-opens` command-line option.)
>
>   - A package of one module can be exported to another module.
>
>     (The Reference Implementation provides this capability via the
>      `--add-exports` command-line option.)
>
>   - A package of one module can be opened or exported to every unnamed
>     module.
>
>     (The Reference Implementation provides this capability by allowing
>      the special token `ALL-UNNAMED` to be used as a target of the
>      `--add-opens` and `--add-exports` command-line options.)
>
> None of these capabilities, for any modules, may be operative by default.
> A future revision of this Specification may disallow these capabilities.

From mark.reinhold at oracle.com  Tue Jul 25 19:39:49 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 25 Jul 2017 12:39:49 -0700
Subject: Updated conformance text for Java SE 9 (JSR 379)
In-Reply-To: <CA+3eh12CyrrLrmNyAXpg7ErT9X3Ef3s+wOjpSvVA7Rmx04bxaQ@mail.gmail.com>
References: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
 <CA+3eh12CyrrLrmNyAXpg7ErT9X3Ef3s+wOjpSvVA7Rmx04bxaQ@mail.gmail.com>
Message-ID: <20170725123949.607155899@eggemoggin.niobe.net>

// Replying to both EG lists, for the record.

2017/7/25 11:15:57 -0700, volker.simonis at gmail.com:
> On Tue, Jul 11, 2017 at 7:10 PM,  <mark.reinhold at oracle.com> wrote:
>> Attached below is revised and expanded text for the "Conformance"
>> subsection of the "Modular platform" section [1] of the Java SE 9
>> (JSR 379) specification.  ...
>> 
>> ----
>> 
>> ...
>> 
>> As an aid to migration, an Implementation may relax the strong
>> encapsulation of the modules that it includes as follows:
>> 
>>  - An Implementation may provide a means to invoke its run-time system
>>    with one or more packages of one or more of its modules open to code
>>    in all unnamed modules, i.e., to code on the class path.  The first
>>    access to an element of such a package by a program via a reflection
>>    API must cause a warning to be issued on the standard error stream.
>>    Later accesses may also cause warnings to be issued.
>> 
>>  - An Implementation may, by default, open one or more packages of one
>>    or more of its modules to code in all unnamed modules.  If it does so
>>    then it must issue warnings as described in the previous paragraph.
>>    If it does so then it must, further, provide a means to invoke its
>>    run-time system without opening any packages of any of its modules.
>> 
>>    (The Reference Implementation's run-time system behaves this way by
>>     default, and because this is the default it can also be invoked
>>     without opening any of its packages via the command-line option
>>     `--illegal-access=deny`.)
> 
> This is still not totally clear to me. Does it mean the specification
> requires at least one warning for each package where we have an
> illegal access, for each module where we have an illegal access or is
> one single warning per invocation of the VM enough?

One single warning per invocation of the VM.  You're right -- this could
be more clear.  How about:

  - An Implementation may provide a means to invoke its run-time system
    with one or more packages of one or more of its modules open to code
    in all unnamed modules, i.e., to code on the class path.  If the
    run-time system is invoked in this way, and if by doing so some
    invocations of the reflection APIs succeed where otherwise they
    would have failed, then the first such invocation must cause a
    warning to be issued on the standard error stream.  Later such
    invocations may also cause warnings to be issued.

Is that better?

- Mark

From mark.reinhold at oracle.com  Tue Jul 25 19:54:20 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 25 Jul 2017 12:54:20 -0700
Subject: Evaluating the TCK for JSR 376
Message-ID: <20170725125420.601074949@eggemoggin.niobe.net>

If any member of this EG would like to evaluate the TCK for this JSR
(i.e., the JCK), and if you do not already have access to it, please
let me know and I'll make the necessary arrangements.

- Mark

From volker.simonis at gmail.com  Tue Jul 25 20:55:25 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 25 Jul 2017 20:55:25 +0000
Subject: Updated conformance text for Java SE 9 (JSR 379)
In-Reply-To: <20170725123949.607155899@eggemoggin.niobe.net>
References: <20170711171038.F369C81DEC@eggemoggin.niobe.net>
 <CA+3eh12CyrrLrmNyAXpg7ErT9X3Ef3s+wOjpSvVA7Rmx04bxaQ@mail.gmail.com>
 <20170725123949.607155899@eggemoggin.niobe.net>
Message-ID: <CA+3eh11MjbVtVVeic0MYu8NGN2Nfjq=5em3rJeyq6qXy9FK-kQ@mail.gmail.com>

<mark.reinhold at oracle.com> schrieb am Di. 25. Juli 2017 um 21:39:

> // Replying to both EG lists, for the record.
>
> 2017/7/25 11:15:57 -0700, volker.simonis at gmail.com:
> > On Tue, Jul 11, 2017 at 7:10 PM,  <mark.reinhold at oracle.com> wrote:
> >> Attached below is revised and expanded text for the "Conformance"
> >> subsection of the "Modular platform" section [1] of the Java SE 9
> >> (JSR 379) specification.  ...
> >>
> >> ----
> >>
> >> ...
> >>
> >> As an aid to migration, an Implementation may relax the strong
> >> encapsulation of the modules that it includes as follows:
> >>
> >>  - An Implementation may provide a means to invoke its run-time system
> >>    with one or more packages of one or more of its modules open to code
> >>    in all unnamed modules, i.e., to code on the class path.  The first
> >>    access to an element of such a package by a program via a reflection
> >>    API must cause a warning to be issued on the standard error stream.
> >>    Later accesses may also cause warnings to be issued.
> >>
> >>  - An Implementation may, by default, open one or more packages of one
> >>    or more of its modules to code in all unnamed modules.  If it does so
> >>    then it must issue warnings as described in the previous paragraph.
> >>    If it does so then it must, further, provide a means to invoke its
> >>    run-time system without opening any packages of any of its modules.
> >>
> >>    (The Reference Implementation's run-time system behaves this way by
> >>     default, and because this is the default it can also be invoked
> >>     without opening any of its packages via the command-line option
> >>     `--illegal-access=deny`.)
> >
> > This is still not totally clear to me. Does it mean the specification
> > requires at least one warning for each package where we have an
> > illegal access, for each module where we have an illegal access or is
> > one single warning per invocation of the VM enough?
>
> One single warning per invocation of the VM.  You're right -- this could
> be more clear.  How about:
>
>   - An Implementation may provide a means to invoke its run-time system
>     with one or more packages of one or more of its modules open to code
>     in all unnamed modules, i.e., to code on the class path.  If the
>     run-time system is invoked in this way, and if by doing so some
>     invocations of the reflection APIs succeed where otherwise they
>     would have failed, then the first such invocation must cause a
>     warning to be issued on the standard error stream.  Later such
>     invocations may also cause warnings to be issued.
>
> Is that better?
>

That's fine!

Thanks,
Volker


> - Mark
>

From volker.simonis at gmail.com  Thu Jul 27 09:50:38 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 27 Jul 2017 11:50:38 +0200
Subject: Evaluating the TCK for JSR 376
In-Reply-To: <20170725125420.601074949@eggemoggin.niobe.net>
References: <20170725125420.601074949@eggemoggin.niobe.net>
Message-ID: <CA+3eh13aRvPLs7dBteh=AyzEr9RnXs1EP_yUWUM4c3xP70pi1w@mail.gmail.com>

Hi Mark,

I have access to the TCK and I did some basic tests with it. The main
problem (which I've already addressed in February but which I was told
won't be fixed for 9) is the following:

The current TCK (i.e. the ModuleGraphTest) only tests the requirements
for specific modules (i.e. tests if all the modules given on the
command line or selected in the harness, have the required export and
requires edges). There are also tests which check the "closure" of a
set of modules (with regard to the 'requires' and 'requires
transitive' relation) but again only for the specific set given on the
command line or choose in the harness.

That's a nice feature for playing around, but I think the TCK
conformance test should by default really use and test all the default
platform modules from the runtime image under test and automatically
tests all these modules (i.e. it should check all exports, all the
requires transitive relations and finally it should check if the
modules form a "closed" subset with regard to the specification (i.e.
'requires transitive') and also a "closed" subset with regard to the
implementation (i.e. 'requires')).

I think this will make it possible for malicious people to certify
custom images which don't conform to the specification (because as far
as I see the TCK doesn't test a complete implementation but just the
part you ask it to test). But you probably already know that.

Regards,
Volker


On Tue, Jul 25, 2017 at 9:54 PM,  <mark.reinhold at oracle.com> wrote:
> If any member of this EG would like to evaluate the TCK for this JSR
> (i.e., the JCK), and if you do not already have access to it, please
> let me know and I'll make the necessary arrangements.
>
> - Mark

From mark.reinhold at oracle.com  Thu Jul 27 18:04:33 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 27 Jul 2017 11:04:33 -0700
Subject: Draft JPMS Proposed Final Draft Specification
In-Reply-To: <20170725021604.1E13C980A7@eggemoggin.niobe.net>
References: <20170725021604.1E13C980A7@eggemoggin.niobe.net>
Message-ID: <20170727110433.803165933@eggemoggin.niobe.net>

2017/7/24 19:16:04 -0700, mark.reinhold at oracle.com:
> I've posted a draft Proposed Final Draft Specification to the usual URL:
> 
>     http://cr.openjdk.java.net/~mr/jigsaw/spec/

FYI, I just posted a new version.  The only change is to the license
file, which was incorrect in the first draft.

- Mark

From Tim_Ellison at uk.ibm.com  Fri Jul 28 16:33:30 2017
From: Tim_Ellison at uk.ibm.com (Tim Ellison)
Date: Fri, 28 Jul 2017 17:33:30 +0100
Subject: Evaluating the TCK for JSR 376
In-Reply-To: <CA+3eh13aRvPLs7dBteh=AyzEr9RnXs1EP_yUWUM4c3xP70pi1w@mail.gmail.com>
References: <20170725125420.601074949@eggemoggin.niobe.net>
 <CA+3eh13aRvPLs7dBteh=AyzEr9RnXs1EP_yUWUM4c3xP70pi1w@mail.gmail.com>
Message-ID: <20170728163546.71201210425@aojmv0009>

"Volker Simonis" <volker.simonis at gmail.com> wrote on 27/07/2017 10:50:38:
> I have access to the TCK and I did some basic tests with it. The main
> problem (which I've already addressed in February but which I was told
> won't be fixed for 9) is the following:
> 
> The current TCK (i.e. the ModuleGraphTest) only tests the requirements
> for specific modules (i.e. tests if all the modules given on the
> command line or selected in the harness, have the required export and
> requires edges). There are also tests which check the "closure" of a
> set of modules (with regard to the 'requires' and 'requires
> transitive' relation) but again only for the specific set given on the
> command line or choose in the harness.
> 
> That's a nice feature for playing around, but I think the TCK
> conformance test should by default really use and test all the default
> platform modules from the runtime image under test and automatically
> tests all these modules (i.e. it should check all exports, all the
> requires transitive relations and finally it should check if the
> modules form a "closed" subset with regard to the specification (i.e.
> 'requires transitive') and also a "closed" subset with regard to the
> implementation (i.e. 'requires')).
> 
> I think this will make it possible for malicious people to certify
> custom images which don't conform to the specification (because as far
> as I see the TCK doesn't test a complete implementation but just the
> part you ask it to test). But you probably already know that.

I think that is a usability request rather than a requirement on the TCK.

While it would be desirable for the TCK to check that the Implementation
adheres to *all* the obligations of the Specification, that is unlikely
to be achievable.

The TCK can't stop "malicious people" claiming compliance where they don't
follow the conditions of the Specification, or run the TCK as intended,
including testing all the SE modules in the Implementation.

However, I agree it is a desirable enhancement and will reduce honest
mistakes.

Regards,
Tim

 
> On Tue, Jul 25, 2017 at 9:54 PM,  <mark.reinhold at oracle.com> wrote:
> > If any member of this EG would like to evaluate the TCK for this JSR
> > (i.e., the JCK), and if you do not already have access to it, please
> > let me know and I'll make the necessary arrangements.
> >
> > - Mark
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From Tim_Ellison at uk.ibm.com  Fri Jul 28 17:07:57 2017
From: Tim_Ellison at uk.ibm.com (Tim Ellison)
Date: Fri, 28 Jul 2017 18:07:57 +0100
Subject: Updated conformance text for Java SE 9
In-Reply-To: <20170725092500.87182169@eggemoggin.niobe.net>
References: <20170711170938.F1AF581DEA@eggemoggin.niobe.net>
 <a200083d-673f-7275-7684-428f3ce3e142@azul.com>
 <20170725092500.87182169@eggemoggin.niobe.net>
Message-ID: <20170728171010.F2B762104C3@aojmv0009>

mark.reinhold at oracle.com wrote on 25/07/2017 17:25:00:
> 2017/7/25 6:48:26 -0700, Simon Ritter <sritter at azul.com>:
> > Mark,
> > thanks for the revised and expanded text.  I think this clarifies 
things 
> > clearly in respect of how a runtime generated using jlink (or a 
similar 
> > tool) conforms to the specification.
> > 
> > There's a still a few things that I'd like to clarify further.
> > 
> > "The Technology Compatibility Kit (TCK) for this Specification will be 

> > able to test all of the Java SE modules included in an Implementation, 

> > and it will require that set to be closed." Presumably, it is not 
> > necessary to run the TCK on all possible combinations of modules to 
> > determine which are closed (and therefore in conformance) and which 
are 
> > not.
> 
> Correct.  If the set of Java SE modules in an Implementation is not
> closed then the Implementation won't even start, never mind pass the
> TCK.  (Or, if it does start then its module system is severely broken,
> and no configuration of it will pass the TCK anyway.)
> 
> > How do we verify that the output from a jlink-like command is in 
> > conformance?  Is there some test or tests that can be run on jlink (or 

> > similar) to guarantee that it can only produce conformant runtime 
> > distributions?
> 
> Um, no.  That would require the ability to solve the halting problem.
> 
> >                 Alternatively, will there be some test tool that can 
be 
> > used on the output of jlink to verify that the Java SE modules 
included 
> > are closed?
> 
> You can verify the output of `jlink`, or a similar tool, by running the
> TCK on that output.  In principle every possible output of such a tool
> must pass the TCK, but (obviously) that's not a testable assertion.
> 
> > "This Specification defines the Licensor Name Space on a 
> > module-by-module basis.  Provided that an Implementation that fully 
> > implements this Specification includes the required Licensor Name 
Space 
> > for each included module then it is not considered to subset the 
> > Licensor Name Space."  The way I interpret this, it means that any 
jlink 
> > produced runtime that includes a closed set of Java SE modules, each 
of 
> > which conforms to the Licensor Name Space, will be deemed to be a 
> > conformant implementation of the Java SE 9 specification.
> 
> No, for (at least) two reasons.
> 
> First, the entire set of Java SE modules that the runtime includes must
> be closed.  That's a different, and stronger, statement than "the 
runtime
> includes a closed set."
> 
> Second, if each Java SE module in a runtime includes the Licensor Name
> Space for that module then you can conclude only that the runtime as a
> whole does not subset the Licensor Name Space.  That's a necessary, but
> not sufficient, condition to claim conformance of a linked runtime.
> The Implementation that was used to create that runtime must itself be
> conformant, which requires (among other things) that it pass the TCK and
> that its linking tool ensures that any linked runtime satisfies all of
> the constraints laid out in the Specification, per the paragraph that
> follows the paragraph that you quoted.
> 
> >                                                           Any user of 
> > such a Java runtime will, therefore, be granted the IP rights as 
defined 
> > by the JSPA (Section 5.B).  Is that correct?
> 
> No, per the above.
> 
> The intent here is that if an Implementation provides the means to 
create
> further Implementations, subject to the constraints of the 
Specification,
> then any user of such a derived Implementation will be granted the
> necessary IP rights.  Your summary of the required conditions, however,
> is incomplete.

Please humour me for a moment -- this is merely a thought experiment, 
IANAL, etc.

So with some selective quoting from the "Java SE 9 (JSR 379) Proposed 
Final
Draft: DRAFT 3" section 7 [1].

> 1. An Implementation must include the java.base module.
> 2. An Implementation may include one or more additional Java SE modules 
...

and later

> An Implementation that passes the TCK is considered to fully implement
> this Specification even if it does not include all of the Java SE 
modules.

Which we agreed is a reference to the "Intellectual Property; Out-Bound"
section of the JSPA 2.0.

That would suggest, taken to the extreme, that a minimal Implementation
containing java.base as the only Java SE module, and passing the TCK for
java.base (i.e. is compliant) affords the user a license covering the
*entire* Specification technology.

It's a hypothetical situation, so I'm not expecting a response.

[1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pfd-spec-03/#Modules

Regards,
Tim


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU