requires public for automatic modules

[Paul Bakker]

Hi Alan,

Thanks, the -addmods hint is a very useful one, I had not tried that yet. After adding the jackson.core and jackson.annotations explicitly to -addmods, I can compile/run without depending on them in my demonstrator module. That's a good workaround.

Paul




> On 22 Apr 2016, at 13:16, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 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.
>