Help My LocalDate Isn't Flattened

Java’s faster dates promised, but tiny details sparked a comment brawl

TLDR: A test build of Java’s Valhalla sped up date arrays by squeezing fields smaller, but a source build didn’t, exposing a trade-off around null values and size limits. Commenters clashed over speed vs stability, with one camp cheering micro-optimizations and another warning against contorted tweaks.

Project Valhalla wants Java’s objects to act like light, fast numbers — think “dates on a diet.” One presenter tried to show it off by flattening LocalDate (Java’s date type) into speedy, packed arrays. The twist? An early-access build from jdk.java.net/valhalla zoomed, but a self-built version crawled. After a “trust, but verify” check, the EA build showed one lean array; the source build showed 50 million chunky date objects. Cue collective gasp.

The culprit was gloriously petty: nulls and a few too many bits. For a date to get flattened by default, it has to fit into 8 bytes, including a “is this null?” flag. The regular LocalDate had year + month + day that summed to 65 bits — one bit over the line. The EA build slimmed month/day to smaller sizes so it squeezed in, and boom, performance. And that’s where the comments caught fire.

Speed fiends cheered the tweak and begged Oracle to “ship the gains.” Backward-compat purists warned that shaving fields for benchmarks smells like trouble. One camp shouted “make Java fast again,” the other replied “don’t break my dates.” Memes flew: “January went keto,” “65-bit date,” and “null remains undefeated.” Everyone agreed on one thing: tiny choices sparked huge drama — and that’s peak Java energy.

Key Points

  • Project Valhalla enables value types that can be flattened in the JVM to reduce object overhead.
  • An EA Valhalla build flattened arrays of LocalDate, improving performance without using internal APIs.
  • Building Valhalla from source did not flatten LocalDate arrays; verification with jcmd GC.class_histogram confirmed the difference.
  • Implicit flattening requires values to fit within eight bytes including a nullness bit; LocalDate with short fields totaled 65 bits and did not qualify.
  • The EA build changed LocalDate to use byte-sized month and day, fitting within eight bytes and enabling flattening; future syntax aims to declare non-null arrays.

Hottest takes

"all these backwards compatibility quirks are ignored, and raw performance is chased instead" — Koffiepoeder
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.