The Glacial Pace of Basic Features in Java Evolution
Description
A screenshot of a social media post, likely from Mastodon or a similar platform, from a user named Riedler. The post is titled 'basic functionality in java.' The main text reads: 'currently requiring java >=18 because they only allow null in match case since then.' This is a classic developer grievance that resonates with experienced engineers. The humor lies in the irony that a seemingly fundamental and essential feature - the ability to handle a 'null' case within a modern pattern matching 'switch' (or 'match') statement - was only added in a relatively recent version of Java (version 18). This forces developers to adopt a very new version of the language, with all the associated migration and dependency challenges, just to access what they consider to be basic, common-sense functionality. It perfectly captures the frustration with the slow, committee-driven evolution of mature, enterprise-focused languages like Java
Comments
7Comment deleted
Requiring Java 18 for a null check in a switch statement is peak enterprise development. It's not about the feature; it's about ensuring the migration project is complex enough to justify a 6-month planning phase
Rolling out JDK 18 across prod just to write “case null” in a switch - turns out the billion-dollar mistake was only the down payment
Java's pattern matching roadmap: teaching a 30-year-old language what Scala knew in kindergarten, one LTS release at a time, while your enterprise is still debating the migration from Java 8
Ah yes, the classic enterprise Java dilemma: your entire microservices architecture now requires Java 18+ because someone on the team discovered they could finally handle null in a switch case without wrapping it in Optional.ofNullable().orElseThrow(). Meanwhile, your legacy monolith is still running Java 8 in production because 'if it ain't broke, don't upgrade 47 transitive dependencies and rewrite half your reflection-based framework code.' Pattern matching is great, but nothing says 'modern Java development' quite like bumping your minimum version requirement by a decade just to avoid one extra if-statement
Amazing how one ‘case null’ turned into an ADR, a toolchains rewrite, and a fleetwide JDK upgrade - apparently NPEs were the cheaper architecture
Upgrading to Java 18 for “case null” - finally the compiler acknowledges the real hot path in our system
Java switch on null since 18: because nothing screams 'enterprise stable' like NPE roulette until the next LTS