Repackaging moves an existing module-info.class file into BOOT-INF/classes

[swaechter]

I am in the process of porting several CLI and Spring Boot applications to Java 12 + Jigsaw modules. This will allow us to create a customized JRE image that is smaller & more secure (Cloud native with Alpine Linux + a 50 MBish JRE).

I was able to port all CLI applications to proper Jigsaw modules - except the Spring Boot ones. The problem is, that the spring-boot-maven-plugin doesn't respect the existing & valid module-info.java and creates an automated module/or drops it (I don't know the exact technical details: Maybe dropping, getting overwritten etc.).

To show you the problem/bug I created a small apllication called springmodule + a few helper scripts (Link: https://github.com/swaechter/springmodule).

The valid original module description of the original JAR looks like this (Can be checked with ./check_module.sh target/springmodule-1.0.0.jar.original or jar --file X.jar.original --describe-module):

swaechter@debian:~/Nextcloud/Workspace_Java/springmodule$ ./check_module.sh target/springmodule-1.0.0.jar.original 
swaechter.springmodule jar:file:///home/swaechter/Nextcloud/Workspace_Java/springmodule/target/springmodule-1.0.0.jar.original/!module-info.class open
exports ch.swaechter.springmodule
requires java.base
requires spring.beans
requires spring.boot
requires spring.boot.autoconfigure
requires spring.context
requires spring.core
requires spring.web
requires spring.webmvc

The Fat-Jar generated by spring-boot-maven-plugin is dropping (I guess?) the module name swaechter.springmodule. An automatic name based on the insecure JAR name detection is instead used (./check_module.sh target/springmodule-1.0.0.jar):

swaechter@debian:~/Nextcloud/Workspace_Java/springmodule$ ./check_module.sh target/springmodule-1.0.0.jar
No module descriptor found. Derived automatic module.

springmodule@1.0.0 automatic
requires java.base mandated
contains org.springframework.boot.loader
contains org.springframework.boot.loader.archive
contains org.springframework.boot.loader.data
contains org.springframework.boot.loader.jar
contains org.springframework.boot.loader.util
main-class org.springframework.boot.loader.JarLauncher

Is it possible to add the original modules to the new module file (Or respect it)? Otherwise it's impossible to use Spring Boot in an Alpine Linux without I guess a few 100 - 200 MBs of Java JRE/JDK.

Not working idea to abuse the orignal JAR module + replace the JAR in the JRE later: /usr/lib/jvm/jdk-12/bin/jlink --no-header-files --no-man-pages --compress=2 --module-path target/springmodule-1.0.0.jar --add-modules springmodule --launcher launch=springmodule/ch.swaechter.springmodule.SpringModule --output custom_jre:

Error: automatic module cannot be used with jlink: springmodule from file:///home/swaechter/Nextcloud/Workspace_Java/springmodule/target/springmodule-1.0.0.jar

[swaechter]

Attached a screenshot of both JAR files (Left original, right fat JAR). Looks like the module-info.class is not staying in the root directory of the JAR:

[wilkinsona]

We have the same problem with the Gradle plugin

[revkov]

Why closed? Now in 2.1.3.RELEASE
"C:\Program Files\Java\jdk-11.0.2\bin\java.exe" --module-path target/springmodule-1.0.0.jar --module swaechter.springmodule/ch.swaechter.springmodule.SpringModule
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: target\springmodule-1.0.0.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Package ch.swaechter.springmodule not found in module

2.1.2 works fine, when module-info.class in BOOT-INF/classes

What's next?

[wilkinsona]

The issue was closed as a fix has been committed. The fix was to stop moving module-info.class into BOOT-INF/classes during fat jar creation.

2.1.2 works fine

2.1.2 did not work fine as shown by the example @swaechter posted above. With 2.1.2, --describe-module did not find the module info and derived an automatic module instead. With 2.1.3, --describe-module now finds the descriptor and describes the module as defined.

2.1.2 works fine, when module-info.class in BOOT-INF/classes

That doesn't match the behaviour reported above by @swaechter or in my own testing. I don't understand how packaging module-info.class in BOOT-INF/classes can work as the module system doesn't know anything about that directory, it's something that's specific to Spring Boot.

If you believe you've identified a problem and there is something that worked with 2.1.2 but no longer works with 2.1.3, can you please open a new issue and provide a minimal sample (as @swaechter took the time to do) that reproduces the behaviour.