Sorry if it is trivial but bc you asked shell command and if meant the "java script.java" no compile way: even that is fast, but if you run in a shell script loop thousand times, then do not forget to compile.

Very fast. And yes, it can be used for small apps too. With java problem now is not the performance but how verbose still it is. However, it's much better since Java 17 and each release make it even more compact and direct. Like in this release we got much better built-in support for JSON.

I'm using JDK 21 (old) and the startup time is sub-second for small programs.

That’s not the flex you seem to think

It wasn't meant to be a flex.

JIT + hotspot optimization makes JVM pretty fast, but warmup time is usually the problem. However it does look like they’re addressing startup time with improvements in this release:

- AOT compilation: https://openjdk.org/jeps/544 - ~100ms startup for ZGC: https://openjdk.org/jeps/545

This is only an issue on OpenJDK, other JVM implementations have had AOT tooling for quite some time.

Every time I try, I keep going back to .NET, which has been optimising for faster startup time.

Almost all Java benchmarks are for the "steady state" after half an hour of warm up time.

Doesn't Java have an AOT solution too? Is it not ready for prime time?

It is, but people like to bash Java ;)

It requires heavy trade-offs.

Depends on which one, there have been several options since the Mac 2000's, which people that know their Java would know.

GraalVM for example places heavy restrictions on reflection usage. It also performs aggressive tree-shaking to include only those classes and methods that are actually going to be executed. Corresponding measures are required for several common libraries to be compatible with GraalVM.

Hotspot's AOT is promising and doesn't have those pitfalls, but has not yet been delivered.

Other posters here seem to misunderstand what AOT means in today's Java. It just means caching some state. There's still a JIT involved, it's just warmer.

There are other solutions that give you MUCH faster startup with lower memory e.g.: https://foojay.io/today/java-server-work-before-startup/

Edit: it seems I missed that 28 added the actual native code compilation phase so it will probably be closer to the GraalVM numbers in the link above.

Like yourself, because depending on which JVM we are talking about there are various kinds of AOT options.

OpenJDK, OpenJ9, Azul, PTC, Aicas, microEJ, ART (even if not Java TM), GraalVM, Bluesoft,..

Startup time depends on whether you are using Spring heavily or not. I wouldn’t use it as a shell script replacement. Use Python to that end.

    $ echo 'class Hello { public static void main(String[] args) { System.out.println("Hello, world"); } }' >Hello.java
    $ javac Hello.java 
    $ java --version
    openjdk 21.0.7 2025-04-15 LTS
    OpenJDK Runtime Environment Zulu21.42+21-CRaC-CA (build 21.0.7+6-LTS)
    OpenJDK 64-Bit Server VM Zulu21.42+21-CRaC-CA (build 21.0.7+6-LTS, mixed mode, sharing)
    $ time java -cp . Hello
    Hello, world
    
    real 0m0.026s
    user 0m0.010s
    sys  0m0.018s

For some reason this machine is still on 21. Anyway, the overhead of the JVM itself is pretty low.

For small tools it's fine:

    $ echo 'class Dig { public static void main(String[] args) throws Exception { var addr = java.net.InetAddress.getByName(args[0]); System.out.println(addr); } }' >Dig.java
    $ javac Dig.java
    $ time java -cp . Dig news.ycombinator.com
    news.ycombinator.com/209.216.230.207
    
    real 0m0.047s
    user 0m0.026s
    sys  0m0.021s

    $ time host news.ycombinator.com
    news.ycombinator.com has address 209.216.230.207
    news.ycombinator.com has IPv6 address 2606:7100:1:67::26
    
    real 0m0.052s
    user 0m0.005s
    sys  0m0.004s

Java startup gets slow when you use some massive framework like Spring. If you need a program to start fast, don't use one!

You can also choose to run directly from source with a small penalty at startup and verbosity has decreased for simple use cases. It's still not great for scripting but the situation has been steadily improving over the last couple of years.

  void main() {
    IO.println("Hello world");
  }

  $ time java Hello.java
  Hello world

  real    0m0.662s
  user    0m2.421s
  sys     0m0.198s

  void main(String[] args) throws Exception {
    IO.println(InetAddress.getByName(args[0]));
  }

  $ time java Dig.java news.ycombinator.com
  news.ycombinator.com/209.216.230.207

  real    0m1.154s
  user    0m2.379s
  sys     0m0.222s

You can also use a shebang and mark the file as executable on Linux:

  #!/usr/bin/java --source 25
  
  void main(String[] args) throws Exception {
    var addr = java.net.InetAddress.getByName(args[0]);
    System.out.println(addr);
  }

Spring is slow because it scans the classpath, uses reflection and generates proxy classes all at startup. You can avoid some of that using the Spring AOT feature in newer versions.

Or you can just use a different framework like Micronaut which does none of that and uses an annotation processor at compile time instead. (Similar to Spring AOT, with fewer limitations)

Loading all them jar files of code was never going to be free.

We use it at scale in different systems. We are moving away from it in our serverless functions due to the cold start times. Other, less latency sensitive services are OK.

What sort of domain are you in? And what are you moving to?

We develop back-end infra related to data streaming (think Kafka). Our main processing engines are written in Java. The control plane uses Lambdas, we are moving those to rust now.

For 20+ years already, most commercial JDKs have had AOT support, long before GraalVM and Open J9 became open source.

But does AOT really help performance wise? It helps with start time, but it probably performs worse after that because of lack of CPU specific optimizations (excluding JIT time).

Yes, just like with C and C++, PGO is the answer, aka training runs.

Also performance for what?

As long production SLA are met, that's a deployment success.

Why are SLAs the bar for performance? Every additional second of execution time accumulates in the annual cloud bill, and using too much memory means I need a bigger box.

For example, the C++ replacement for a Java program bottlenecking my CI takes 1/3rd as long (with less variance) and runs on a smaller instance.

Because engineering salaries matter.

You missed to account the hours spent writing the application in C++, related memory and UB bugs, the additional security issues plugging a language like C++ directly into the Internet.

Additionally, you also failed to account Java has JNI, which means only a few hot-spots might be rewriten into something like C++, not the whole application.

Finally, with Panama, it is possible to design a memory layout off heap, similar to what would be done with C++.

Naturally this requires some low level programming skills, the benefit is that one keeps enjoying the ecosystem.

Finally, SLAs also include execution time, of course.

Won't address start up time since it's so affected by which libraries you pull. Slow starts are usually related to dependency injection frameworks like Spring or Guice, which admittedly is what most nontrivial projects will tend to use.

Performance depends a lot on how you write the code. Inefficient Java code is often quite slow, but you can get surprisingly close to C++ speeds with Java in many cases, but that involves a lot of byzantine rules of how to write code so that it e.g. omits bounds checks. More realistically if you don't pay any attention you're probably running at like a 25-50% speed penalty.

Java has a leg up on statically compiled languages in that it does automatic PGO based on real run-time data which helps bridge the gap to a surprising degree. GC is also a lot more resistant to memory fragmentation from repeated small allocations than malloc, which can help as well, not just from its generational approach but also e.g. TLAB space.

It's a bit held back by not having decent access to SIMD intrinsics. Maybe will resolve itself when the Vector API gets finished baking eventually.

There's ongoing work to improve JVM startup time. [1]

So long as you are willing to do a training run, you can get pretty decent startup times.

[1] https://openjdk.org/projects/leyden/