One advantage of a Spring Boot executable jar is that it contains all of your application's code as well as its dependencies. This gives you a single unit that you can deploy. When you're packaging your application in a container, it becomes this single unit of deployment with the added benefit that it also contains the JVM and anything else your application needs. Given that the container is a single unit of deployment, the jar packaging arguably isn't needed any more.
As described in the Spring Boot reference documentation, unpacking the executable jar when building the container can result in a slight improvement in startup time. You can explode the jar file and then use Spring Boot's JarLauncher
to launch the exploded "jar":
$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher
This approach ensures that the classpath has the same order as it would have when running the application using java -jar
.
Alternatively, you can specify the classpath manually and run the application's main method directly:
$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication
This will result in a further small boost in startup time at the cost of potentially changing the order of the classpath.