[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: The baby and the bathwater (the return)
From:       Alan Bateman <Alan.Bateman () oracle ! com>
Date:       2018-06-04 6:44:27
Message-ID: c3ae1fa3-bf98-8977-c556-aa0c1111bde8 () oracle ! com
[Download RAW message or body]

On 03/06/2018 20:43, Remi Forax wrote:
> Hi all,
> There were discussions on that list [1] about the fact that beginning with Java 9, \
> there were 2 ways to deploy modules, classpath vs module-path. 
> I've discovered last Friday there that are not 2 configurations but 3 \
> configurations. You can also use jlink [2] and in that case, the modules are not \
> loaded though the module-path but are considered as system modules, so a library \
> should also be tested with that configuration. 
> In my case, Spring Boot annotations scanning works with the classpath, works with \
> the module-path but fails if deployed as system modules [3]. 
The module path is exactly as Jon said.

I haven't looked at your demo in github but it sounds like the issue is 
the code that does the scanning the module path (Spring code? Some other 
library?). Is it limited to modules that are packaged as modular JAR 
files or is it that it just scans the value of the jdk.module.path 
property? In terms of behavior then there shouldn't be any difference of 
course, code in a module loaded from the application module path should 
work the same as when the module is linked into the run-time image. In 
both cases, the modules are mapped to the application class loader.

Separately, it would be interesting to know if the scanning is all 
observable modules or the modules that have already been resolved and 
are in the boot layer. If this is all "discovery" then I assume it must 
be looking for observable modules that have not been resolved as they 
will be candidates to load into a child layer. There may be some 
interesting topics to discuss there but it's completely independent on 
where the modules are deployed on the application module path or linked 
into the run-time image.

-Alan


[prev in list] [next in list] [prev in thread] [next in thread]