Volker originally sent this to the java-se-9-spec-comments list, but now
that he's on the EG I figured I'd just reply here.
2017/2/22 10:04:26 -0800, volker.simonis(a)gmail.com:
> referring to the "Java SE 9 (JSR 379) Early Draft Review
> Specification" I'd like to get some clarifications regarding the
> definition of the "Modular platform" and its implications on
> implementors of Java SE 9.
>
> Section "7 Modular platform" of the specification starts with the
> statement that it "..uses the Java Platform Module System, specified
> by JSR 376, to modularize the Java SE Platform". One of the goals is
> to "Divide the Java SE Platform into a set of modules that can be
> combined at compile time, build time, or run time into a variety of
> configurations including, but not limited to..Custom configurations
> which contain only a specified set of modules and the modules
> transitively required by those modules."
>
> What is "compile time, build time, or run time" referring to? Is it
> the "compile time / build time" of the platform itself?
No, it's referring to those phases in the development of a library or
application that runs on top of Java SE 9.
> I.e. should it
> be possible for an implementor to only build and assemble a subset of
> the standard modules into his "Java SE Platform"?
That's a different question, and the answer is "yes".
> And will this still
> be called "Java SE 9"?
Yes, that's the intent.
> Later on, in the "Conformance" section, the specifications mentions
> that "Every Implementor of this Specification must implement the
> java.base module. 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.".
>
>> From this and the previous statement I would expect that an
> independent implementor as well as an OpenJDK distributor could build
> a "Platform implementation'" which only contains the java.base module,
> certify that with the Java SE 9 TCK (because "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.") and provide that to its customers. Is that
> correct?
Yes, that's the intent.
> And if it is correct, how could a user of such a "Platform
> implementation" distinguish two different implementations which
> provide a different subset of standard modules? Currently, as far as I
> can see in the RI, running "java -v" always identifies itself as
> "Java(TM) SE Runtime Environment (build 9-ea+xxx)", no difference
> which modules it contains. The user would have to run "jimage list"
> on the modules file to find out which modules are included (not to
> mention that "jimage" isn't a standard tool anyway).
The Java SE Platform Specification has never specified command-line
tools, so there's no such thing as a "standard" tool.
>From a pure SE perspective, you can distinguish implementations that
contain different sets of modules by examining the set of modules in
the boot layer via the API:
java.lang.reflect.Layer.boot().modules().forEach(System.out::println);
>From the command line, the RI supports a `--list-modules` option that
does much the same thing.
> That said, the "Goals" section also mentions that "standard modules
> that are part of the Java SE Platform Specification, and thereby
> mandatory in every Platform Implementation" which seems to contradict
> with the above points which explicitly allow sub-setting (as long as
> that set is closed).
That text is incorrect -- the "mandatory" clause should be removed.
Thanks for catching this inconsistency.
> Finally, it would be good to have a new version of the "OpenJDK
> Community TCK License Agreement" (OCTLA) available BEFORE the final
> vote on JSR 379. I understand that standardization and licensing are
> two different things. But first, JSR 379 explicitly references the TCK
> and second voting on a new standard which technically allows
> sub-setting and modularization is pointless if these new possibilities
> would be prohibited by licensing. At least the current OCTLA [1]
> explicitely states that a "Compatible Licensee Implementation" has to
> "..fully implements the Java Specification, including all its required
> interfaces and functionality..".
Work on an updated OCTLA is in progress.
- Mark