Quite the opposite. Java is almost all about an optimising runtime with deep telemetry, and it helps with exactly the things AI needs the most help: https://youtu.be/fXBGBovpH88
I now manage a team writing languages on the jvm. I have found the jvm ecosystem terrible for observability. Examples;
- junit parallelisation - how are shards handled? how do you balance the tasks across forked processes? What is the bottleneck? Options are
1) pay someone for better tooling or 2) write your own
- long pauses in garbage collection - how do you know which objects are causing the pauses? the options;
1) profiling 2) analysing heap dumps that you periodically capture 3) add metrics or gc logging
- what is the performance bottleneck? options
1) profiling
Sure AI can do this stuff, but it's painful and time consuming
Contrast it to Elixir on the BEAM;
- exunit parallelization - basically free and because you don't have coupling due to OOP. mocks are basically an antipattern
- long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.
- performance bottleneck? Open inspector and see what is doing all the reductions, and if any of the inbox queues are backlogged. You don't have to profile, you can just look in production
- memory? Open inspector and sort processes by size descending. Again no profiling needed
JFR is what you'd use for everything you need to know. It's depth and breadth are unmatched.
> Contrast it to Elixir on the BEAM;
Java is in the same performance class as C++. BEAM is wonderful in its own way, but it's not even in the same performance class as Go.
BEAM was designed for some interesting resilience in distributed systems. The JVM was designed to address the performance issues that programs in C++ and other low-level languages suffer from when they get large and/or are maintained/evolved for a long time.
> long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.
GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.
We're talking past each other a bit. I was just trying to give examples of where observability on the jvm isn't that great, because you were were stating it's where AI needs the most help.
The parent was saying these new features don't matter as much post-AI and i think I agree with them. The AI can just write in rust if you need to optimise a hot loop, but if you need observability, you could do worse than the BEAM.
> GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.
yeah that's a fair comment, zgc is a lot better for pauses. I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices. If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.
> Yah but why? The things it was good at doesn’t really matter nearly as much post AI.
Pretty much the opposite. Those who disliked it usually cited having to type too much due to class verbosity and variable verbosity (the former has merit, the latter was purely a choice).
If you no longer need to type in any of the code, what better than a language with a blazing fast and scalable runtime, with excellent debugging and monitoring support.
But if you want "blazing fast" performance then there are other languages like Rust that the AI can write, and Rust runs basically everywhere Java does these days (and more) except perhaps Android, for which there are still ways around it.
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 :)
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 startup time 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.
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.
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.
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.
It's really refreshing to see the pace of Java development pick up so much over the past few years.
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.
Yah but why? The things it was good at doesn’t really matter nearly as much post AI.
Quite the opposite. Java is almost all about an optimising runtime with deep telemetry, and it helps with exactly the things AI needs the most help: https://youtu.be/fXBGBovpH88
I now manage a team writing languages on the jvm. I have found the jvm ecosystem terrible for observability. Examples;
- junit parallelisation - how are shards handled? how do you balance the tasks across forked processes? What is the bottleneck? Options are 1) pay someone for better tooling or 2) write your own
- long pauses in garbage collection - how do you know which objects are causing the pauses? the options; 1) profiling 2) analysing heap dumps that you periodically capture 3) add metrics or gc logging
- what is the performance bottleneck? options 1) profiling
Sure AI can do this stuff, but it's painful and time consuming
Contrast it to Elixir on the BEAM;
- exunit parallelization - basically free and because you don't have coupling due to OOP. mocks are basically an antipattern
- long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.
- performance bottleneck? Open inspector and see what is doing all the reductions, and if any of the inbox queues are backlogged. You don't have to profile, you can just look in production - memory? Open inspector and sort processes by size descending. Again no profiling needed
JFR is what you'd use for everything you need to know. It's depth and breadth are unmatched.
> Contrast it to Elixir on the BEAM;
Java is in the same performance class as C++. BEAM is wonderful in its own way, but it's not even in the same performance class as Go.
BEAM was designed for some interesting resilience in distributed systems. The JVM was designed to address the performance issues that programs in C++ and other low-level languages suffer from when they get large and/or are maintained/evolved for a long time.
> long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.
GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.
We're talking past each other a bit. I was just trying to give examples of where observability on the jvm isn't that great, because you were were stating it's where AI needs the most help.
The parent was saying these new features don't matter as much post-AI and i think I agree with them. The AI can just write in rust if you need to optimise a hot loop, but if you need observability, you could do worse than the BEAM.
> GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.
yeah that's a fair comment, zgc is a lot better for pauses. I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices. If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.
> Yah but why? The things it was good at doesn’t really matter nearly as much post AI.
Pretty much the opposite. Those who disliked it usually cited having to type too much due to class verbosity and variable verbosity (the former has merit, the latter was purely a choice).
If you no longer need to type in any of the code, what better than a language with a blazing fast and scalable runtime, with excellent debugging and monitoring support.
But if you want "blazing fast" performance then there are other languages like Rust that the AI can write, and Rust runs basically everywhere Java does these days (and more) except perhaps Android, for which there are still ways around it.
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.
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'm not a Java person, but I'm curious how fast it is nowadays, and also the startup time. Can it be used to write shell commands with, for example?
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 ;)
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.
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.
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 startup time with improvements in this release:
- AOT compilation: https://openjdk.org/jeps/544 - ~100ms startup for ZGC: https://openjdk.org/jeps/545
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.
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.
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:
Java startup gets slow when you use some massive framework like Spring. If you need a program to start fast, don't use one!
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.
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
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.
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.
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/ )
JEP 540: Simple JSON API
Be strict in what you produce, be lenient in what you accept. Grr.
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.
Apples and oranges.
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.“
> 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.
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.