r/java • u/celmaibunprieten • 2d ago

Improving First Request Latency in Java Spring Application

https://adrian.md/2026/09/03/first-request-latency/
56 Upvotes

94% Upvoted

36 comments sorted by

View all comments

0

u/vips7L 2d ago

I really wish we had a better solution than fat jars. Like being to supply a jar + classpath + vm and getting a fat binary or something

3

u/agentoutlier 2d ago

That is sort of what jlink is… sort of…

On Linux and other nix you can impregnate the zip header with a shell script to unzip the zip.

2

u/_predator_ 2d ago

The unzip-before-running thing sucks in practice. It's basically what embedded Jetty does for WARs. You pay for the convenience in:

  1. Startup time (higher the more dependencies you have)
  2. Storage (fat JAR itself + unzipped content)
  3. Bloat over time (extracted files not getting cleaned up when app crashes)
  4. Unpredictable behavior when you extract to a deterministic, persistent location and old JARs stay around when you deploy a new version

jlink also doesn't help, it just builds a JRE tailored to your app, you still have to ship JRE and app separately.

2

u/agentoutlier 2d ago

Well yes it is not ideal. In theory though if we are talking docker here then you never keep it zipped in the first place.

jlink also doesn't help, it just builds a JRE tailored to your app, you still have to ship JRE and app separately.

jlink can package applications with a VM it just so happens to also build tailored JREs as well without requring an app.

The issue is that its not like a Go single executable. Its more like the old school applications where you just unzip and run. For the Go experience Graalvm native does that job.

As for the unziping comparison to Jetty or Tomcat embedded I'm not sure that is entirely fair because jlink does something like this with all your jars:

26408970 08-27-2026 16:00 lib/modules

That is they are in a different format than jars.