Jigsaw related questions emerged during Java 9 Jigsaw Hack Day

[Alex Buckley]

On 8/14/2017 1:35 AM, Oleg Tsal-Tsalko wrote:
> Recently we run Java 9 Jigsaw Hack Day in Kiev, Ukraine and several
> questions have been raised:
>
>     1. When declaring 'exports' in module descriptor why wildcard are not
>     supported like com.abs.*?

The packages exported by a module are meant to be a stable API that 
consumers can rely on. For this reason, we make the module author spell 
out the exported packages explicitly. This also dials down the 
likelihood of multiple modules needlessly exporting the same package. 
Additionally, it avoids the confusion that would occur if com.abs.* was 
exported without qualification while com.abs.foo was exported with 
qualification.

>     2. Why compilation doesn’t fail in case several modules with same name
>     put on module-path, but it only fails in runtime on startup (
>     https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/master/session-1-jigsaw-intro/08_ModulesExportConflict
>     )?

When compiling src/com.greetings/module-info.java, javac resolves 
'requires org.astro;' by

1) searching the modulepath for a directory called org.astro, then

2) seeking a module-info.class file in that directory which declares a 
module called org.astro.

The directory is found successfully (mods/org.astro), and a 
module-info.class file is found in that directory which declares 'module 
org.astro {..}'.

javac is disinterested in the existence of another directory 
(mods/org.astro2) which contains another declaration for a module called 
org.astro. If we assume that directories are named sensibly, that is, in 
accordance with the modules they declare, then it's reasonable for javac 
to ignore mods/org.astro2. javac observes just enough to compile what it 
was given on the command line -- it does not validate the world. In 
contrast, the Java runtime is in a good position to validate the world, 
so it's reasonable for the runtime to detect and complain about 
duplicate modules called org.astro. This should all be documented in JEP 
261.

>     3. What is the best practice for using `transitive` dependencies? Where
>     to use them apart of cases when type of one module are used in API of
>     another module like return types, etc.?

Apart from API dependencies, 'requires transitive' is useful for 
declaring "aggregator" modules such as java.se.

>     4. If there are 3 conflicting modules in module path error says only
>     about 2 first modules conflict only. Why that? Fail fast?

This is really a request for better traceability of which modules are 
observed and resolved, which is fair.

Alex