This could be a good middle ground between our current standard deployment artifact, and the GraalVM/SpringNative optimized executable (see #93). This would be an optional add-on, perhaps as a distinct rule, something like:
With the JDK jlink tool, we should be able to produce a small JDK+app executable. In one published example, this reduced the size of the runnable jre from 286MB to 39MB. This works because the jre distro will only contain the Java platform modules that are needed to run the app, and not all the extra cruft (corba, rmi, etc) that are not.
There are a few examples of Spring Boot users getting this to work online, but all of them seemed to use manual methods. Because we have the full list of deps for the Spring Boot jar, we could invoke jdeps with high fidelity, and use that when invoking jlink.
This could be a good middle ground between our current standard deployment artifact, and the GraalVM/SpringNative optimized executable (see #93). This would be an optional add-on, perhaps as a distinct rule, something like:
With the JDK jlink tool, we should be able to produce a small JDK+app executable. In one published example, this reduced the size of the runnable jre from 286MB to 39MB. This works because the jre distro will only contain the Java platform modules that are needed to run the app, and not all the extra cruft (corba, rmi, etc) that are not.
https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4
There are a few examples of Spring Boot users getting this to work online, but all of them seemed to use manual methods. Because we have the full list of deps for the Spring Boot jar, we could invoke jdeps with high fidelity, and use that when invoking jlink.