requires public for automatic modules

[Alan Bateman]

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.