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.bate...@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.
>
