Custom configurations and definition of "closed set"
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed Apr 26 21:23:39 UTC 2017
2017/3/28 6:29:11 -0700, volker.simonis at sap.com:
> the public review version of the Java SE 9 spec  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
> 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
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!
More information about the java-se-9-spec-observers