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 [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


More information about the java-se-9-spec-experts mailing list