Java 26 is here

Original Article ↗ Hacker News Discussion ↗

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.