Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[Juergen Hoeller]

Alan,

In my last round of testing, application modules had to declare not only
"requires spring.context" but also "requires spring.core", since
spring.context - as an automatic module - couldn't bring in spring.core
transitively. Explicitly adding those through --add-modules is a way out
that I'm aware of, and a motivation for Spring-provided aggregator modules
was indeed to resolve all transitive automatic modules.

You're saying that such transitive resolution of automatic modules happens
implicitly now, i.e. "requires spring.context" implicitly makes spring.core
visible to the application module when both spring.context and spring.core
are automatic modules on the module path? That would be great, of course,
since it makes the Spring ecosystem significantly nicer to use as automatic
modules for the time being! We have plenty of interfaces and classes that
depend on types from several modules (e.g. aggregate several interfaces
into a facade), so there are plenty of corresponding transitive
dependencies between our own modules. With our Maven POMs, those are all
brought in automatically, so people are really used to just referring to
spring-context, not even being aware that this brings in spring-core.

I admit I have yet to revisit my Jigsaw sample app with a recent JDK 9
build, so thanks a lot for raising this!

Juergen


On Wed, Apr 26, 2017 at 1:25 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 25/04/2017 09:48, Juergen Hoeller wrote:
>
> :
>>
>> For the time being, we'll have to keep focusing on the use of our
>> framework
>> jars as automatic modules... which works fine for us so far. Even if the
>> lack of transitive dependencies is a bit of a nuisance, there is enough
>> value for somebody choosing to adopt Jigsaw at the application level.
>>
> Juergen - can you say any more about the issue with transitive
> dependences? I suspect your mean you are forced to run with `--add-modules
> ALL-MODULE-PATH` or the equivalent with the aggregator module to ensure all
> the automatic modules are resolved, is that right?
>
> One recent change to be aware is that automatic modules are now resolved
> more eagerly that previously. Specifically, if one automatic modules is
> resolved (required by an explicit module or --add-modules) then all
> observable automatic modules will also be resolved. This really helps the
> usability when a bunch of JARs are moved from the class path to the module
> path.
>
> -Alan
>