Updated conformance text for Java SE 9
sritter at azul.com
Mon Jul 31 22:52:44 UTC 2017
I am happy for the specification to be submitted, as is. I believe that
any change required will be minor and quite acceptable after PFD.
On 31/07/2017 18:09, Iris Clark wrote:
> Hi, Simon.
> Thank you for providing feedback. I need to submit the current
> draft PDF to the PMO for publication today by 23:59 UTC to allow
> for additional comments and feedback from the public, per my
> message last Friday .
> The JCP Process allows us to make additional changes to the
> Specification after PFD. I believe that my co-Spec Lead, Mark,
> will be able to address your feedback next week, and meanwhile,
> unless you object, would like to proceed with submitting the
> current draft PFD for publication.
> : http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2017-July/000040.html
> -----Original Message-----
> From: Simon Ritter [mailto:sritter at azul.com]
> Sent: Monday, July 31, 2017 5:06 AM
> To: Mark Reinhold <mark.reinhold at oracle.com>
> Cc: java-se-9-spec-experts at openjdk.java.net
> Subject: Re: Updated conformance text for Java SE 9
> On 25/07/2017 12:25, mark.reinhold at oracle.com wrote:
>> 2017/7/25 6:48:26 -0700, Simon Ritter <sritter at azul.com>:
>>> 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
>>> similar) to guarantee that it can only produce conformant runtime
>> 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.
> The question that this raises is, how does someone who uses a further implementation know that that implementation has been created subject to the constraints of the specification? The initial implementation must, of course, pass the TCK. However, guaranteeing IP rights for derived implementations requires the TCK to be run on all derived implementations, which the vast majority of users are not able to do.
> I think that it needs to be made clear in the specification that the output from jlink (or a similar tool) whilst in theory is a conformant runtime is not automatically granted IP rights unless the TCK has verified it to be conformant.
>> - Mark
More information about the java-se-9-spec-observers