j-vogel

6 ms·

1. 1.▲
   by j-vogel 6mo ago

   Good catches from several of you. The original fix dropped the try-catch entirely which was a regression for overflow and edge cases like a bare "-". Updated the post to keep a try-catch around the final parseInt as a safety net.
2. 2.▲
   by j-vogel 6mo ago

   Author here. DB and external service calls are often the biggest wins, thanks for calling that out. In my demo app, the CPU hotspots were entirely in application code, not I/O wait. And across a fleet, even "smaller" gains in
3. 3.▲
   by j-vogel 6mo ago

   Author here. Great callout. That's the -XX:+OmitStackTraceInFastThrow optimization, been around since JDK 5. The C2 compiler detects exceptions thrown repeatedly from the same site and starts reusing a preallocated instance without fil
4. 4.▲
   by j-vogel 6mo ago

   Fair point on ecosystem decisions, that's basically the thesis of the post. These patterns aren't Java being slow, they're developers (myself included) writing code that looks fine but works against the JVM. Enterprise Java g
5. 5.▲
   by j-vogel 6mo ago

   I'm a fan of Rust too. But there are millions of Java applications running in production right now, and some of them are running these anti-patterns today. Not everyone has the option to rewrite in a different language. For those teams