Authoritative definition of module dependencies, relationships and contents

[Volker Simonis]

Hi Alan,

thanks for your quick response!

Your explanation definitely makes sense.
I've sent a follow up mail with the specification relevant parts of my
question to the java-se-9-spec-experts mailing list [1].

Regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2017-March/000016.html


On Mon, Mar 27, 2017 at 10:56 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 27/03/2017 19:34, Volker Simonis wrote:
>
>> Where can I find the authoritative definition of the Java SE 9 module
>> dependencies and relationships?
>
> JSR 379 / Java SE 9 isn't final yet so I think you'll have to use material
> in the public review in the mean-time.
>
>>
>> When I'm looking at the "Modular platform" [1] section of the "Java SE
>> 9 Public Review Specification", I can see the "module graph". Its
>> module dependencies seem to correspond to the Java 9 API documentation
>> [2]. For the "java.desktop" package for example, both define
>> "java.datatransfer" and "java.xml" as its transitive dependencies.
>> However when I'm looking at the source code [3], I can see that
>> "java.desktop" also requires "java.prefs" (non-transitively). Why is
>> this dependency not recorded in the module graph and the API
>> documentation?
>
> It's an implementation dependency. It doesn't influence the API that is
> exposed when you require the java.desktop module.
>
>>
>> For "java.corba" it seems even more confusing. The API documentation
>> list "java.desktop" and "java.rmi" as transitively required, but also
>> explicitly "java.datatransfer" and "java.xml" as "additionally
>> required" modules, although they are implicitly reachable trough
>> "java.desktop" anyway. On the other hand, the module-info of
>> "java.corba" [5] only lists "java.desktop" and "java.rmi" as
>> transitively required but not "java.datatransfer" and "java.xml".
>> Additionally "java.logging", "java.naming" and "java.transaction" are
>> required non-transitively (but these requirements are not recorded,
>> neither in the module graph nor in the API documentation).
>
> org.omg.CORBA.ORB.init(Applet, Properties) is the reason why java.corba has
> to `requires transitive java.desktop`.
>
> RMI-IIOP is part of the java.corba module and types from java.rmi are
> exposed in the API, this is why it `requires transitive java.rmi`.
>
> The others are implementation dependences. The exception is the dependency
> on java.transaction which requires digging into the Java Language to IDL
> Mapping specification and the table that maps CORBA system exceptions to RMI
> exceptions.
>
>> :
>>
>> 3. Is it acceptable for an "independent implementation" to add
>> additional "requires" and/or "requires transitive" edges from a
>> standard module to another standard module?
>
> I assume this will be covered by the documentation for certifying a Java SE
> 9 implementation.
>
> However just to say that if you change module M to `requires transitive X`
> then you expose the X API to whoever requires M. So I expect `requires
> transitive` (or "implied readability" as it is termed) will feature in the
> module graph equivalent of the signature test.
>
>>
>> 4. Were can I find the authoritative package to module mapping
>> mandated by the Java SE 9 standard? Is this just the current Java 9
>> API documentation?
>>
> Yes.
>
> -Alan