The baby and the bathwater (the return)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

The baby and the bathwater (the return)

Remi Forax
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].

regards,
Rémi


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html
[2] http://openjdk.java.net/jeps/282
[3] https://github.com/forax/pro-demo/tree/master/spring-demo
Reply | Threaded
Open this post in threaded view
|

Re: The baby and the bathwater (the return)

Jonathan Gibbons
Rémi,

Generally, you should consider the runtime "module path" to be composed
of three elements: the upgrade module path (--upgrade-module-path), the
system modules (--system) and the user module path (--module-path). 
Depending on your requirements, you may want to take --patch-module into
account as well.  At compile time there is also the source path
(--source-path or --module-source-path) to consider.

While this may seem complicated, it is analagous of the pre-Jigsaw world of

     -Xbootclasspath/p:  -bootclasspath  -Xbootclasspath/a: -classpath  
(and -sourcepath at compile time)

-- Jon


On 6/3/18 12:43 PM, 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].
>
> regards,
> Rémi
>
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html
> [2] http://openjdk.java.net/jeps/282
> [3] https://github.com/forax/pro-demo/tree/master/spring-demo

Reply | Threaded
Open this post in threaded view
|

Re: The baby and the bathwater (the return)

Jochen Theodorou
On 03.06.2018 21:53, Jonathan Gibbons wrote:

> Rémi,
>
> Generally, you should consider the runtime "module path" to be composed
> of three elements: the upgrade module path (--upgrade-module-path), the
> system modules (--system) and the user module path (--module-path).
> Depending on your requirements, you may want to take --patch-module into
> account as well.  At compile time there is also the source path
> (--source-path or --module-source-path) to consider.
>
> While this may seem complicated, it is analagous of the pre-Jigsaw world of
>
>      -Xbootclasspath/p:  -bootclasspath  -Xbootclasspath/a: -classpath
> (and -sourcepath at compile time)

with one major difference... you rarely had a reason to use
bootclasspath in any way. The need to test such situations was very very
limited as well. jlink makes system modules a standard, classpath and
modulepath have to be tested as well now...

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: The baby and the bathwater (the return)

Alan Bateman
In reply to this post by Remi Forax
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