Thank you Alex for detailed answers! 2017-08-14 22:47 GMT+03:00 Alex Buckley <alex.buck...@oracle.com>:
> 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 >
