At FastComments we run our E2E tests on the new instance to JIT the app. Before the Jit API calls can take 100ms, and after 10-30ms. Still, that is fast enough that most people wouldn't notice...
Also, the problem is not Java. Your application probably has way too many abstractions for a simple login page.
There is a huge DI framework full of reflection and proxy classes, then a complex JIT to make the framework performant and now finally a scheduled warmup/load test phase to make the JIT work.
It seems like the same or better performance could be archieved with far less complexity by using an AOT compiled language.
I was never really a fan of DI.
Part of my point is your application should be fast enough before the JIT kicks in.
Ideally, you should also do performance testing. Incorporating that with your release go or no go is a great approach, IMO, if you do releases very often.
Or use reflection free frameworks like Micronaut or Quarkus and enjoy the same productivity. The culprit here is no java, the spring framework.
Because it's probably a whole lot less work to add this new deployment mechanism than to completely change languages. Even for new projects there are tons of other things to factor in when picking a language; a crutch in one area can sometimes be the right call.