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.
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.
JIT + hotspot optimization makes JVM pretty fast, but warmup time is usually the problem. However it does look like they’re addressing it with improvements in this release:
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.
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
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)
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.
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.
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).
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.
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.
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.
One is „accept a wide array of syntactically malformed input, ill defined, substantially complicating the parser“, the other „accept two trivial extensions to the standard that are widely used and don’t affect the resulting data in any way.“
So far nobody has tried to get trailing commas into the standard AFAIK.
Comments were explicitly disallowed from JSON since the beginning, because they could be used as a side-channel for vendor-specific extension mechanisms and harm interoperability.
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.
From the perspective of the one and only app you care about it may improve operability of that app with others.
But from the perspective of a potentially distributed ecosystem of apps and libraries as employed in practice in modern systems, it's actually harmful to interoperability.
Other libs/services/apps that touch the malformed JSON that this change would accept might be present in the overall system and crash on that data. The risk grows with the more components of the overall system that silently accept malformed data and allow the bad data to make its way deeper before it causes issues.
This is what “fail fast” was meant for, if something is going to cause problems in your system at some point in the future, make that “some point” happen ASAP, so that it is easier to identify and fix the source of the flaw.
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 :)
Sure, Java is slowly getting most of the features and sometimes even in a better form because they control the runtime (virtual threads arguably just work). But IMO Java is still incredibly verbose, Kotlin's type system is just better and I've genuinely never come across anything that would be easier to do in Java. Even virtual threads can be used from Kotlin.
I would never use the proposed style for Java. This is simpler and easier to understand for anyone with basic knowledge of Java. Readability is more important than fancy features:
For me, Java 8 was tolerable. Also used IJ a lot and it hides Java verbosity and reduced a lot of typing. That's why I didn't really see the need to switch. For better or worse, these days I don't even open IJ and just use VSCode + AI Badger mostly to review my changes. Language matters even less.
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.
> 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.
I couldn’t find it in the docs, but does the OpenJDK contain Java’s GUI? It would be cool to write the backend in whatever language you want and then have an ACTUAL library that works on all platforms that also looks like the system GUI
Swing with the Nimbus Look and Feel isn't too bad for a quick, functionality-focused widget and it's super handy to have it still built into the JDK. It's not a good option for building a long term desktop application UI now though. There is no on-going development, the focus is now in Java FX. Prior to AI tooling, finding answers to Swing questions was getting much harder. Surprisingly I've found Claude to be pretty good at providing simple Swing UIs.
This is the answer for native theming, but you do end up opting in for a more difficult build process to make it work (JNI libraries and generation). Most devs will choose AWT/Swing because it's a lot simpler.
Most people are thirsting for value objects but I'm mostly looking forward to:
542: PEM Encodings of Cryptographic Objects
543: Structured Concurrency
Developers work with certificates a bit too seldom to aquire proficiency with conversions. Being able to use PEM directly will ease a lot of pain.
I've given concurrency a couple of attempts over the years and I don't... like... or understand?... how the existing Java concurrency primitives are supposed to work. The only library that has clicked with me is Awaitility but for some reason Awaitility is intended for testing and not for production. Maybe Structured Concurrency will finally unlock something for me?
65 comments
[ 2.5 ms ] story [ 33.7 ms ] threadAlmost all Java benchmarks are for the "steady state" after half an hour of warm up time.
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.
OpenJDK, OpenJ9, Azul, PTC, Aicas, microEJ, ART (even if not Java TM), GraalVM, Bluesoft,..
- AOT compilation: https://openjdk.org/jeps/544 - ~100ms startup for ZGC: https://openjdk.org/jeps/545
For small tools it's fine:
Java startup gets slow when you use some massive framework like Spring. If you need a program to start fast, don't use one!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)
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.
So long as you are willing to do a training run, you can get pretty decent startup times.
[1] https://openjdk.org/projects/leyden/
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.
One is „accept a wide array of syntactically malformed input, ill defined, substantially complicating the parser“, the other „accept two trivial extensions to the standard that are widely used and don’t affect the resulting data in any way.“
That's always how it starts. If they're truly trivial the reasoning also cuts the other way. Remove them upstream.
Comments were explicitly disallowed from JSON since the beginning, because they could be used as a side-channel for vendor-specific extension mechanisms and harm interoperability.
But from the perspective of a potentially distributed ecosystem of apps and libraries as employed in practice in modern systems, it's actually harmful to interoperability.
Other libs/services/apps that touch the malformed JSON that this change would accept might be present in the overall system and crash on that data. The risk grows with the more components of the overall system that silently accept malformed data and allow the bad data to make its way deeper before it causes issues.
This is what “fail fast” was meant for, if something is going to cause problems in your system at some point in the future, make that “some point” happen ASAP, so that it is easier to identify and fix the source of the flaw.
The last few years of server-side has been on Kotlin for me, however, modern Java is looking more and more like anything I'd need in a language.
I love Java and I’m so glad it’s kept improving so much despite all the turmoil in its ownership.
Sure, Java is slowly getting most of the features and sometimes even in a better form because they control the runtime (virtual threads arguably just work). But IMO Java is still incredibly verbose, Kotlin's type system is just better and I've genuinely never come across anything that would be easier to do in Java. Even virtual threads can be used from Kotlin.
if (obj instanceof Point p) {
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 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.
There is also JavaFX, but that is no longer bundled with the JDK.
* React replacement: Flavour ( https://frequal.com/Flavour/book.html )
* Vanilla JS equivalent: TeaVM ( https://www.teavm.org/ )
I've given concurrency a couple of attempts over the years and I don't... like... or understand?... how the existing Java concurrency primitives are supposed to work. The only library that has clicked with me is Awaitility but for some reason Awaitility is intended for testing and not for production. Maybe Structured Concurrency will finally unlock something for me?
While I certainly welcome this in the JDK, in practice it hasn't been a huge issue since a lot of people just use Bouncycastle to get that support.