Birbla

Discussion summary

Discussions highlight that low-latency Java is possible but requires discipline and skill, with performance often comparable to or better than other languages like C++ or Rust in certain scenarios.

What the discussion says

  • Java can achieve low latency with proper discipline and skilled developers.
  • Languages like C++, Rust, and Go often outperform Java but may be harder to troubleshoot.
  • Java's JIT compiler is highly effective, making performance competitive.
  • Performance depends on implementation and developer expertise, not just language choice.
“Java being slow is most often a pebcak scenario.”
— ecshafer
“The Java JIT is a masterpiece of several hands.”
— motoboi

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by opentokix
  • It is a matter of skill.
    by pjmlp
  • Java is a great language and runtime. Java being slow is most often a pebcak scenario. There are massive, fast, low latency, Java systems out there that have been written by competent developers.
    by ecshafer
  • I've done some tests with current value classes in latest prototype with full optimisation through annotation. Apparently, everything was being compiled to assembly code with no gc calls. It seems this old school ideology of slow java is about to end in near future. I'm actually intrigued how it will compete with Rust which can't optimise code further while running, while JVM JIT has more info which it could aggressively further optimise, especially hot paths.
    by joe_mwangi
  • 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.

    by motoboi
  • > Average go, rust, c++ and c will outperform amazing java programs

    Everyone that has a minimal experience with these knows it is not true.

    While performance ceiling is likely higher in C/C++/Rust (but not Go), when we move beyond microbenchmarks Java provides competitive performance with much better ergonomics. Not to mention strictly superior tooling.

    by wolvesechoes
  • > Average go, rust, c++ and c will outperform amazing java programs

    Not true. Many benchmarks have shown otherwise. it is at least competitive in many areas.

    > and the former will also be way way more easy to run, troubleshoot, interpret logs from

    No language will save you from poor logging practices. If you log every debug log it's not Java's problem. No 1 says you have to log the full stack trace if that's your concern. You can configure / strip / do anything. Learn to use the stack.

    by re-thc
  • >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.

    by ksec
  • 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).

    C and C++ are dangerous languages filled with security failings and footguns, and no modern app should be written in them.

    It's been my experience that well-written low-level Java code runs at about 75% the speed of good C code. (Of course lazy coders write in cushy Java which is much slower). When written efficiently, Java's biggest slowdown lies in array access (C and C++ array access is fast because it is very, very unsafe). But Java makes up for this in having a GC which will coalesce related objects into the same page and so take advantage of cache coherency effects in ways malloc and free cannot possibly do. I have some allocation-heavy algorithms in Java which are, as a result, significantly faster than well-written equivalents in C.

    by SeanLuke
  • page doesn't load "En attente de la réponse de chronicle.software."
    by dominicrose
  • + low latency anything requires discipline. if you lose 5ms you can't get it back.
    by PaulHoule
  • On mobile the whole page text is aligned center which makes it really hard to read.
    by treyd
  • Chronicle has a lot of great resources. I’ve been out of Java for a few years but when I had to write high perf code, the libraries and blog insights were invaluable.

    A lot of the advice is good in general - keeping things simple, generating fewer objects, etc. Profiling with Yourkit or JMH to find and improve slow spots.

    This let us build high performance software that had a vast difference in say p90 input size and p99. It involved rewriting third party libraries to let us 3x speed and substantially reduce GC. I think in the end we were around a p99 of 7ms and p90 well under that (the data spread was kbs to megabytes) across hundreds of millions of inputs per day.

    by gwittel
  • Even C requires discipline to write low latency code, if you think otherwise, you never used a profiler.
    by pjmlp
  • And Compiler Explorer also
    by madduci
  • Yes. & in the end my experience has been that you can write low latency code with gc, but only by expending more effort than it'd take to use manual memory management
    by __s
  • Had to write a router software once in Java back in 2014. The past experience in me believed that its not a good choice to use something with stop the world GCs for routers. The goal was to have everything under 1ms (max 2ms in rare cases). It has http server on head and websocket connections on the tail end. Turns out the class instantiations and JSON parsing were a bottleneck. Thread safe resources were valuable, the libraries which did not had thread safe resources were re-written to support what we needed. The http server was re-written barebones, the JSON parsing was re-written with barebones. And it worked.
    by sandeepkd
  • I get that blog posts often advertise a company's products, but this one had absolutely zero content other than advertising.
    by chuckadams
  • Yes, disappointing given that Chronicle actually does have legit expertise here. (Chronicle Map is not very well-known even in the Java space but it's by far the best larger-than-memory Map available.)
    by jbellis
  • This is a high-level article; for lower-level details, I also posted.

    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.

    by peter_lawrey
  • I think it said something very meaningful and actionable (admittedly at a high level) about keeping the hot path deterministic: low allocations (including guidelines for GC frequency targets), don't use vthreads (instead use one thread on a pcore that never sleeps, to avoid amdahl), caution about techiques that work at p99 and fail at 99.999... This is not typical for "enterprise" Java, and is an interesting article for those who wish their systems were more deterministic (but may not be aware of the techniques or their cost). This is not a "how to", but that's fine. It's still good content.
    by simpaticoder
  • 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.

    by motoboi
  • That sounds like a great idea. What kind of prompt do you use?
    by declan_roberts
  • Take a peek at jolokia if you've never used it :) Attach it as a JVM agent to _any_ process to expose it's JMX attributes as http calls, and it even gives you a neat little console to log into.

    If you want to collect these, telegraf has a jolokia plugin. It's an incredible combination!

    by exabrial
  • 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.
    by haglin