Java 25's new CPU-Time Profiler

Original Article ↗ Hacker News Discussion ↗

Java’s evolution and stewardship

  • Many comments praise the last 6–8 years of JVM innovation and recent Java releases (esp. post‑21) as making the language “fun” again.
  • Several express surprise that Java is thriving under Oracle, given its broader reputation, but acknowledge that stewardship of the platform has been strong.
  • Others note that multiple large vendors sponsor work (e.g., the JEP behind the profiler), not just Oracle.
  • Some nostalgia: appreciation for Java tends to increase after suffering large JS/Python codebases.

Language strengths, weaknesses, and ecosystem

  • Java is described as highly maintainable and “the COBOL of the 90s/2000s” in a positive sense: ideal for long‑lived, business‑critical systems.
  • Safety and portability of the JVM are praised; major knocks are JNI’s awkwardness (with FFM seen as its replacement) and relatively high memory usage.
  • Some argue Java’s real problem is “enterprise” frameworks and design patterns rather than the language itself.

Tooling, builds, and debugging

  • One camp criticizes fragmented tooling: multiple build systems, fragile XML configs, version mismatches, and Spring’s heavy indirection making debugging painful.
  • Others counter that Maven/Gradle with toolchains and wrappers are “good enough” or excellent compared to Python/JS env tooling; building is typically mvn package / gradle build.
  • Several strongly defend Java’s debugging and monitoring (IDEs, remote debugging, profilers, Mission Control) as among the best available. Claims that Java is harder to debug than assembly are widely rejected.

GC, performance, and memory management

  • A claim that serious performance work shouldn’t use GC languages is widely labeled outdated.
  • Multiple comments argue modern tracing GCs are extremely fast; the main tradeoff is memory footprint, not throughput.
  • There’s an extended side‑discussion on whether reference counting is a form of GC (most argue yes) and how Rust‑style ownership complements, rather than replaces, GC in some designs.
  • A referenced talk suggests using more RAM per core can be the right tradeoff to conserve CPU.

Virtual threads vs reactive/async

  • Some hope virtual threads will let them abandon complex reactive/async frameworks, which they view as an “unproductive mistake” for most apps.
  • Others argue reactive/async provides better models for concurrency and explicit backpressure, which virtual threads do not magically solve.
  • Counterpoints emphasize that the real benefit of virtual threads is cheap, blocking I/O (goroutine‑like), and that backpressure can still be expressed with classic synchronous constructs.

Profiling: CPU-time vs wall-time

  • A question notes that CPU‑time profiling can overemphasize regions with many concurrent threads, whereas wall‑time is better for spotting serial bottlenecks.
  • The new Java profiler is described as sampling‑based, built atop Linux facilities; Apple’s Instruments offers exact CPU tracing for native code but lacks deep understanding of Java frames.
  • The blog author mentions a multi‑part series covering implementation details, queue sizing, and synchronization optimizations for the profiler.