21–30 of 56 posts
I get that blog posts often advertise a company's products, but this one had absolutely zero content other than advertising.
https://blog.vanillajava.blog/2026/06/testing-java-memory-ma...
https://blog.vanillajava.blog/2026/06/why-you-should-tun-cod...
Suggestions welcome, it can be hard to know what to include or not.
I found claude and GPT very helpful on this, because java have a very sofisticated monitoring harness. Just ask the agent to connect to the running application (on kubernetes or whatever) on prod and do a java flight recording then analyze allocations. I managed to improve some applications of ours from several garbage collections per second to several minutes between collections. That _really_ improves p99.
If you want to collect these, telegraf has a jolokia plugin. It's an incredible combination!
How about not using Java? Then you can have low latency. Average go, rust, c++ and c will outperform amazing java programs, and the former will also be way way more easy to run, troubleshoot, interpret logs from. Java is usch garbage in every stack.
Rust? OK. C++ or go? Then you'll have to take a very closer look, because the java JIT is wonderful. A masterpiece of several hands, actually.
How about not using Java? Then you can have low latency. Average go, rust, c++ and c will outperform amazing java programs, and the former will also be way way more easy to run, troubleshoot, interpret logs from. Java is usch garbage in every stack.
I need a UI which runs well on Windows, MacOS, and Linux, without having to build three different ones. Swing is still easily the best, most consistent, and most native-feeling cross-platform environment. It's much better than QT and GTK in most respects. And Java also runs elegantly on a little platform you may know as Android. I have high hopes for go and rust. But until they have mature UIs, they're out (for me).…
I've done a lot of performance engineering in both C++ and Java. Every optimization available in Java also exists in C++ but the reverse is not true, which is why C++ is always faster. Every example I have ever seen of Java being faster than C++ was just poorly optimized code. The heuristic I use is that heavily optimized C++ is about twice as fast as heavily optimized Java at the limit. And this requires some non-idiomatic and ugly Java that isn't nice to maintain.
This doesn't necessarily make Java the wrong choice though. Few organizations prioritize absolute performance above all other things. There are practical tradeoffs.
How about not using Java? Then you can have low latency. Average go, rust, c++ and c will outperform amazing java programs, and the former will also be way way more easy to run, troubleshoot, interpret logs from. Java is usch garbage in every stack.
I need a UI which runs well on Windows, MacOS, and Linux, without having to build three different ones. Swing is still easily the best, most consistent, and most native-feeling cross-platform environment. It's much better than QT and GTK in most respects. And Java also runs elegantly on a little platform you may know as Android. I have high hopes for go and rust. But until they have mature UIs, they're out (for me).…
Earlier quoted context omitted.
Rust? OK. C++ or go? Then you'll have to take a very closer look, because the java JIT is wonderful. A masterpiece of several hands, actually.
If low latency is your goal than you don't want JIT. JIT has two issues in low latency, first the first time through your code isn't compiled yet and so you get high latency. Second, it optimizes for the common case, which means when you hit an exception that exception will be higher latency because everything hits a branch miss. Of course we are talking generals here. Sometimes the above is acceptable and Java/JIT i…
To avoid the compilation etc. hit, common practice is to do some "warmups" before serving users. (Another reply has other ways to avoid this hit.)
Handling exceptions is higher latency, but they can/should be optimized out, so you're not hitting exceptions as part of your standard workflow (or even your 1% workflow).
Even C requires discipline to write low latency code, if you think otherwise, you never used a profiler.
How about not using Java? Then you can have low latency. Average go, rust, c++ and c will outperform amazing java programs, and the former will also be way way more easy to run, troubleshoot, interpret logs from. Java is usch garbage in every stack.
May be true between late 90s to late mid 10s. Both Java and JVM has had enormous of work going into it. 2026 the JVM is pretty damn good pieces of engineering.
I get that blog posts often advertise a company's products, but this one had absolutely zero content other than advertising.
I found claude and GPT very helpful on this, because java have a very sofisticated monitoring harness. Just ask the agent to connect to the running application (on kubernetes or whatever) on prod and do a java flight recording then analyze allocations. I managed to improve some applications of ours from several garbage collections per second to several minutes between collections. That _really_ improves p99.
I work on OpenJDK, so I may be biased, but I’ve also found that JFR works really well with LLMs. $ java -XX:StartFlightRecording:maxsize=10M,filename=dump.jfr -jar app.jar $ jfr view all-views dump.jfr > report.txt $ jfr print dump.jfr > all.txt Then ask Codex, or whatever AI tool you use, to analyze report.txt for issues and use all.txt to dig deeper, if needed.
There's also async profiler. LLMs just use whatever. Lots of choices.