Custom configurations and definition of "closed set"
Simonis, Volker
volker.simonis at sap.com
Tue Mar 28 13:29:11 UTC 2017
Hi,
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".
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?
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?
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)?
Regards,
Volker
[1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec-02/java-se-9-spec.html
More information about the java-se-9-spec-observers
mailing list