I never fully switched to Kotlin. It’s good, but not good enough. I also like the direction Java has been evolving in over the last 10 years, to the point that a JVM server is actually lighter than a Node.js server :)

I see no reason other than Android, where Android engineers live in the past and don't bother to support modern Java, other than when Kotlin starts to lose the amount of Java libraries able to run on Android.

Many years ago I learnt that mastering the language that goes alongside the platform is quite valuable versus the languages that come and go.

Hence why despite my rants, I keep my C knowledge up to date, as it is the language of UNIX, same with JavaScript on the Web, Erlang on BEAM, and naturally Java on the JVM, even though Scala and Clojure are much cooler.

I’m so glad they made that change. So much better than the old days.

I love Java and I’m so glad it’s kept improving so much despite all the turmoil in its ownership.

> see the pace of Java development pick up so much over the past few years.

I don't think that is a fair assessment. Java / JVM has been steadily progressing in the past 10 - 15 years. From languages to different part of JVM. It is only getting the sense development being picked up because HN and other social media are finally getting the clicks and interest again. The pendulum swing back because of all of different reasons.

And in reality a lot of these recent landed improvement were 5 - 10 years in the making.

I still don't like its syntax though. But I am not even sure if it is even an issue in AI driven development era.

Yah but why? The things it was good at doesn’t really matter nearly as much post AI.

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.

    $ 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 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

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

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.

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

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.

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.

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

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.

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.

It is bundled with Swing and AWT, but neither really looks like native, which has been a consistent complaint about them.

There is also JavaFX, but that is no longer bundled with the JDK.

You can also make web frontends in Java for over a decade. This allows a full-stack app in Pure Java:

* React replacement: Flavour ( https://frequal.com/Flavour/book.html )

* Vanilla JS equivalent: TeaVM ( https://www.teavm.org/ )

Eclipse SWT ?

Easy, change the default JVM.

Fortunately, we now have 50 years of evidence of the negative effects of this philosophy on the ecosystem. Being strict in both results in net positive effects for the entire ecosystem. Trying to be lenient in what you accept results in HTML5, where the exact parse tree for every possible input sequence is specified in order to enforce compatibility. It's no longer lenient, because that doesn't work.

From the JEP's goals: "Provide only those data types and operations required for strict conformance to RFC 8259, in order to facilitate machine-to-machine communication."

In that case they made the right choice, as machines won't be inserting trailing commas or comments in the first place, and the risk of having consuming apps inadvertently accept invalid data would be high otherwise.

This is a great way to ensure you have good application interoperability, but really starts going down hill when you're talking about security and consistency.

that was good advice back then. It is not good advice in 2026