Remove support for embedded jar launch scripts

[vpavic]

It's been a decade since all major Linux distributions adopted systemd as their init system. See https://en.wikipedia.org/wiki/Systemd#Adoption for some information about the adoption.

Spring Boot still supports SysVinit, which is at this point quite archaic, and this support comes with some complexity as evident by the amount of documentation that describes it - including some notable shortcomings of prepending script to a JAR.

Additionally, launch script integration tests are quite complex and resource intensive and take a lot of time when building the project while objectively providing little value considering that shouldn't be the way to run Spring Boot applications in 2025. See this breakdown of build tasks as an example.

This is a formal request to deprecate, and eventually remove, support for SysVinit. There has been some previous mention of this in #28453 (comment).

[philwebb]

We discussed this today and we'd like to remove the ability to prepend a launch script entirely. It's an issue that causes problems with tools and it goes against our recent efforts to move towards unpacking jars for performance gains.

[garretwilson]

A major benefit of a prepended launch script is that one can distribute a Linux Java command that will just run, with no installation needed other than having a JVM installed on the system. This is extremely useful for making utility CLIs in Java. Otherwise we are stuck with the enormous overhead (and huge files) of something like Rust.

Let me see if I understand this decision correctly. If I want to distribute a foobar command, written in Java, to run on Linux:

Current Situation:

• I distribute a single executable foobar file.
• The user places the foobar in the user application directory.
• The user executes foobar.

After This Decision

• I distribute a foobar.zip file.
• The user extracts foobar.zip into some directory that contains shell scripts and JAR files.
• The user adds some symlink from the application directory to some main shell script inside the new foobar extracted contents.
• The user executes foobar.

Now suddenly distributing (or upgrading!) a simple CLI written in Java becomes as much a chore as installing Maven or Tomcat!

[vpavic]

Launch script provided by Spring Boot takes on a lot of concerns that are better off handled by init system since the main use case for it has been installing/running Spring Boot applications as system services.

What you're describing sounds like a different concern and that is packaging CLI Linux applications. There are ways simpler that relying on a Spring Boot prepended script to achieve that, like using Gradle's application plugin (not sure what's Maven equivalent).

[snicoll]

+1 to Gradle's application plugin. Maven has the assembly plugin (and perhaps others). What you've described @garretwilson isn't a great fit for a CLI, IMO. Especially for those you'd want to bypass the bootloader and start a quickly as possible. With the infrastructure in place, this would be

• I distribute a single foobar.zip file.
• The user unzip foobar.zip wherever they want to (for instance in the user application directory).
• The user executes <directory>/bin/cli.sh.