From mark.reinhold at oracle.com  Wed Apr 26 20:51:51 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 26 Apr 2017 13:51:51 -0700
Subject: Question regarding the "Modular platform"
In-Reply-To: <dfc39fd0-9d7d-110a-d052-006d0befcc31@azul.com>
References: <CA+3eh13PruwJa_L0qMnG5fDB84PGUk-_E4naXBMABas6Kgtf8A@mail.gmail.com>
 <20170309004927.9485481637@eggemoggin.niobe.net>
 <dfc39fd0-9d7d-110a-d052-006d0befcc31@azul.com>
Message-ID: <20170426135151.686241235@eggemoggin.niobe.net>

2017/3/9 3:56:12 -0800, Simon Ritter <sritter at azul.com>:
> thanks for the answers you've provided.  I have some follow-on and 
> related questions.

Thanks for your questions.

Our intent is to allow custom run-time images generated by the `jlink`
tool to be redistributed in the same way that a full Java SE JRE can
be redistributed, without any need for further conformance testing.

Your questions about IP flow are legal questions which, not being an
attorney, I cannot answer directly.  I've asked Oracle Legal to advise
on a response; I'll post that here once I receive it.

- Mark

From mark.reinhold at oracle.com  Wed Apr 26 21:00:41 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 26 Apr 2017 14:00:41 -0700
Subject: Mandatary nature of standard Java SE modules
In-Reply-To: <15c3cc98b4794717851bcd22abb3f341@DEROTE13DE07.global.corp.sap>
References: <15c3cc98b4794717851bcd22abb3f341@DEROTE13DE07.global.corp.sap>
Message-ID: <20170426140041.333761146@eggemoggin.niobe.net>

2017/3/28 6:09:07 -0700, volker.simonis at sap.com:
> in a previous conversation (see below) I objected the wording in the
> "Goals" section which stated that "standard modules that are part of
> the Java SE Platform Specification" are "mandatory in every Platform
> Implementation". You agreed and removed that sentence from the latest
> 'public review' version of the specification.
> 
> While digging deeper into the specification, I found a similar phrase
> in subsection 4 of the "Design principles" section which states that
> "If a standard module is a Java SE module, i.e., is mandated by this
> Specification, then it must not export any non-SE API packages, at
> least not without qualification".
> 
> I think the subsentence ".. i.e., is mandated by this Specification
> .." should be removed because the specification doesn't mandate all
> Java SE modules.

You're right again; thanks for pointing this out.  We'll fix this in
the Proposed Final Draft.

- Mark

From mark.reinhold at oracle.com  Wed Apr 26 21:23:39 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 26 Apr 2017 14:23:39 -0700
Subject: Custom configurations and definition of "closed set"
In-Reply-To: <e56d88445b5e4da995e237223c1ca029@DEROTE13DE07.global.corp.sap>
References: <e56d88445b5e4da995e237223c1ca029@DEROTE13DE07.global.corp.sap>
Message-ID: <20170426142339.815252191@eggemoggin.niobe.net>

2017/3/28 6:29:11 -0700, volker.simonis at sap.com:
> the public review version of the Java SE 9 spec [1] mentions in the
> "Goals" section that it allows "Custom configurations which contain
> only a specified set of modules and the modules transitively required
> by those modules". Later on in the "Conformance" section it specifies
> that "every Implementor may, further, implement a set of one or more
> additional standard SE modules so long as that set is closed, i.e.,
> contains every standard module required by any member of the
> set". This sentence is unclear, because it doesn't seem to make a
> distinction between "required" and "transitively required". According
> to the "Goals" section (and the "modular graph" picture) I think this
> sentence should read "..contains every standard module TRANSITIVELY
> required by any member of the set".

Yes, you're right.  We'll fix that wording, and further make it clear
that we're specifically talking about `requires transitive` directives
in module declarations rather than just ordinary transitive closure.

We'll also reword the phrase "Custom configurations which contain only a
specified set of modules and the modules transitively required by those
modules" to remove "only", which I think will address your next
question.

> But even with the corrected wording, this can lead to a situation
> where one Implementor's concrete "closed" subset of a valid "custom
> configuration" contains different/additional standard modules compared
> to the concrete "closed" subset of another Implementor's
> implementation of the same "custom configuration". As an example,
> imagine that implementor A implements a "java.desktop"
> configuration. According to the specification he also has to implement
> "java.xml", "java.datatransfer" and "java.base" because these three
> modules are all in the transitive closure of "java.desktop" (with
> regard to the "requires transitive" relation). A second implementor B
> also implements "java.desktop", but he decides to use "java.logging"
> in his implementation of the "java.desktop" module. So he "requires"
> (non-transitively) "java.logging" in "java.desktop". Implementor B's
> "java.desktop" configuration will now contain "java.logging" while
> implementor A's implementation of the same configuration will not
> contain "java.logging".
> 
> 1. Are both, A's and B's, implementations of "java.desktop" standard
> conforming?

Yes.  B's use of `java.logging` is merely an implementation detail, and
while it affects the final set of modules in a custom configuration its
presence is not mandated by the SE 9 Specification as a consequence of
the presence of the `java.desktop` module.

> The "Conformance" section also states that "The Technology
> Compatibility Kit (TCK) for this Specification will be structured to
> allow testing of arbitrary configurations of SE modules present in a
> Platform Implementation".
> 
> 2. What will be the scope of the TCK testing for a "closed" subset?
> Will it be the set of "transitively required" modules as mandated by
> the standard or will it be the, usually bigger, set of actually
> required modules of the concrete implementation? So in the previous
> example, will the TCK test for the "java.desktop" configuration also
> test "java.logging" for implementor B's implementation of the
> "java.desktop" configuration?

The TCK will test the "transitively required" closure of all of the
standard modules in a configuration.  Thus if `java.logging` is present
only because it's used by the implementation of `java.desktop` then
`java.logging` will still be tested.

> 3. Finally, am I right with my assumption that only the "requires
> transitive" relation between modules is governed by this specification
> and the JCP? Or, in other words, is every Implementor free to add an
> arbitrary number of simple "requires" relations from one standard
> module to other standard modules at his discretion (assuming he will
> not introduce dependency cycles)?

Yes, that's correct.  We'll review all of the text prior to PFD with the
aim of making this clear.

Thanks again for the detailed comments!

- Mark