Java 26 is here

Original Article ↗ Hacker News Discussion ↗

Java 26’s release prompts broad reflection on how far the language and JVM have evolved, from virtual threads and modern GC to a steadily cleaned-up standard library and long-awaited projects like Valhalla and the Vector API. Commenters contrast this rapid progress with lagging Android compatibility, awkward build and packaging tooling, and a lingering “enterprise” culture that pushes many teams toward alternatives like Go, Kotlin, TypeScript, or Python. Even so, many argue that the JVM’s performance, observability, and mature ecosystem keep Java highly competitive for large-scale, long-lived systems despite its rough edges.

Android, Java, and the Oracle legacy

  • Android uses its own runtime (ART/Dalvik) and DEX bytecode; it can ingest JVM bytecode but is not a full OpenJDK JVM.
  • Some say Android only cherry-picks OpenJDK since Nougat and lacks full bytecode equivalence; others note Google internally uses full OpenJDK on server-side.
  • Lawsuit fallout: several argue Google froze Java language levels after Oracle’s actions, then pushed Kotlin as primary.
  • Result: Android often lags mainstream Java (e.g., long delay for lambdas, now a Java 17 subset), making library compatibility painful.

Virtual threads, green threads, and “function coloring”

  • Many praise virtual threads as Java’s “async without colored functions”: blocking APIs stay synchronous while getting async-like scalability.
  • Discussion clarifies “function coloring” (async vs sync call graphs) and differences between stackless vs stackful coroutines.
  • Some note virtual threads don’t entirely eliminate pinning problems or misuse of blocking APIs, but remaining pitfalls are narrow (e.g., FFI).

Applet removal and legacy APIs

  • JEP 504 (removing Applet API) is widely welcomed; Java browser plugins and WebStart are remembered as painful but historically important.
  • A minority regret removal because JApplet-based code still exists and can run via IDE plugins or WASM.

Language evolution, culture, and frameworks

  • Long-time users say modern Java is far nicer: records, pattern matching, sealed types, streams, virtual threads, better GC.
  • Others claim “you don’t code Java, you code Spring Boot,” criticizing annotation-heavy, enterprise patterns and painful upgrades.
  • Counterpoint: the Java ecosystem is diverse; many teams avoid Spring entirely or use lighter frameworks (Quarkus, Micronaut, Helidon, Javalin, Jooby) or Jakarta EE.
  • Persistent complaint: “Java culture” (over-OO, factories, DI obsession) bleeds into other languages; others argue composition, simpler styles, and more procedural code are now common.

Java vs Go, .NET, TypeScript, Python

  • Several compare Java favorably to Go for large “industry” codebases: richer typing, immutability patterns, better GC, deeper observability (JMX, JFR).
  • Others report concrete cases where Go web services used far less memory and CPU than Java equivalents; they attribute differences partly to frameworks and GC pressure.
  • .NET/C# is seen by some as ahead in language features and compiler/tooling; others say JVM GC and cross-platform reach are stronger.
  • TypeScript is preferred for full-stack web and shared types, but criticized for chaotic tooling and NPM security vs Java’s curated Maven Central.

Tooling, build, and deployment pain

  • Strong consensus that Java’s build/deploy story is weak: Maven/Gradle are slow or complex; jlink/jpackage and Graal native are powerful but hard and slow.
  • Mill and jbang are cited as promising alternatives; many want a “java package”-style simple bundling flow akin to Go’s single-binary builds.
  • Packaging and runtime-version headaches are blamed for Java’s decline on the desktop and for CLI tools.

Projects Valhalla and Vector API

  • Valhalla (value types) is seen as massively important but comically slow; some joke you could measure cosmic timescales in “nano-Valhallas.”
  • Vector API remains incubating, waiting on Valhalla; some are frustrated, others note recent real progress and backward-compatibility constraints.

Impact on other JVM languages

  • Non-Java JVM languages benefit mainly from runtime improvements (GC, virtual threads, new APIs).
  • Clojure and Kotlin can already tap virtual threads; some note many “new” Java features are things Kotlin had syntactically earlier.