On 22/04/2016 09:52, Paul Bakker wrote:
Why don't automatic modules take better care of transitive dependencies, so
that the application's module-info looks similar to what it would after
transforming the dependencies to named modules?
As Rémi said, there isn't any static analysis done at compile time or
run time to figure out the dependences. It would be costly to do this
and of course no guarantee that it would be accurate/complete.
For that reason, automatic modules are specified to only require
java.base and you can confirm this if you use -listmods to list/describe
these modules:
java -mp lib -listmods:jackson.core,jackson.databind,jackson.annotations
So in your scenario then "demonstrator" requires jackson.databind but
there is nobody that transitively depends on jackson.core or
jackson.annotations and so neither module is resolved. You can of course
use -addmods if you need it.
I guess it's worth repeating that automatic modules are for migration
and bridging to the class path. In the scenario then you'd like to
create a module "demonstrator" that depends on Jackson databind but that
project hasn't embraced modules yet. You move jackson-databind-2.6.jar
to the module path where it becomes a module with a name
("jackson.databind" in this case) and that allows you to make progress
on compiling and deploying "demonstrator" as a module. At this point
then you can leave the other JAR files on the class path and the code in
jackson.databind will link to whatever types it needs from the other
Jackson components.
-Alan.
