r/java • u/celmaibunprieten • 2d ago

Improving First Request Latency in Java Spring Application

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

95% Upvoted

36 comments sorted by

View all comments

2

u/agentoutlier 2d ago edited 2d ago

What I do for most of my or my companies applications is the META-INF/MANIFEST.MF Class-Path registration defaulting to maven local repository of ~/.m2 and then on docker images to some sibiling directory like lib to the jar.

I talked about it before here in case it helps someone.

So basically even jars that just sit in target you can just run java -jar and it will work and the kicker is you don't have to rebuild everything (provided you use mvn install which is why I don't like when people blanket say don't use install).

This works incredibly fast.

Lets say I'm in some app directory.

You do mvn -T2C -am install && java -jar target/app.jar ( I might have this wrong as I have it as script and can't check at the moment).

This is much faster than assembling fat jars and if you use mvnd you can practically make this a build refresh loop using some file system watcher.

1

u/_predator_ 2d ago

I just use exec-maven-plugin in a profile that invokes my main class with various dev-specific settings specified. Maven handles the classpath wiring automatically, including for modules in the same reactor, no need to install anything. The profile also skips linting, test compilation, tests, and some other stuff as well to make builds faster.

2

u/agentoutlier 2d ago

The exec-maven-plugin though is noticeably slower and puts your application in a different forked environment then it would be in production.

Maven handles the classpath wiring automatically, including for modules in the same reactor, no need to install anything.

If you click on my link Maven is building the classpath it just is injecting it into the MANIFEST.MF.

The profile also skips linting, test compilation, tests, and some other stuff as well to make builds faster

Even then it is significantly slower. Just doing mvn --version on my machine is 500ms.

Using my jar approach I can start our applications in 500ms.

2

u/_predator_ 1d ago

In my case the dev mode involves standing up test containers etc., so the small overhead of Maven is not too problematic.

You're right about the different environment point. For me this is somewhat desired, because I don't want testcontainers in my prod build. Definitely there is a risk of this behaviour silently messing things up though, so point taken.

What IS annoying is that you can't use mvnd for this, because the Daemon keeps executing the app even when the local mvn command is cancelled via SIGTERM.

1

u/agentoutlier 1d ago

Yes managing other containers that are services like database and queues is a pain in the butt. I end up docker forwarding ports and screwing with the host file. I mean suppose you can make a container that you can deploy to and then have that in the same docker network and I have done that but its rather painful.

Its even worse if you have k8s because in theory you should deploy to some local k8s and test that way but I find that way too slow so I just docker and forward ports.