[javaone 2025] interested in where the language is going

Speaker: Brian Goetz

See the table of contents for more posts


Note: I was 15 minutes late to this session as I was doing a book signing:

Patterns

  • like expressions turned inside out
  • data flows from the environment into the expression
  • If expression succeeds, produces a result
  • Patterns compose like expressions
  • Payoff is that Java is better at dealing with Java
  • OOPs strong suit (complex entities/boundaries) became less important. Data has become more important
  • Pattern matching allows us to sometimes recover lost details – ex: type
  • Eventually can decompose any class, not just records.
  • Will impact API design
  • Lots of work left. Started with features that are easiest to understand.
  • Will use for marshalling in future

Valhalla

  • Goal is flatter and denser memory layouts for Java object graphs, unify the type system (primitives vs objects), enabling new numeric types as libraries rather than new primitives
  • Big refactoring
  • While JVM doesn’t specify object layout in memory, have to use pointers
  • Locked into existing layout – objects have identity so can only have one copy, references re nullable so need certain number of bits, kept discovering more
  • Primitives were necessary in 1995 for performance bug has dogged us ever since. Like original sin.
  • Rift widened in Java 5 with generics and then again in Java 8 with lambdas
  • Primitives are a performance hack for flatness and density
    • JEP 401 – value classes – not all objects need identity . If don’t need, JVM has more flexibility and can store however wants. Implicitly final. == uses state not identity. No intrinsic monitor.
    • Use as few degrees of freedom as possible. Favor private over public. Favor final over mutable. Favor value over identity
    • Flattening should be a JVM optimization. Language model should be about program semantics. Give up things that are impediments to flattening.
    • Nullability is a density and flatness hazard. Also a safety hazard. Not all code wants/needs nullability; place for bugs to hide
    • Future JEPS – null restricted types, null restricted value types, minimize gaps between int and Integer and surely more

My take

It was nice hearing about these features from Brian’s POV. While I didn’t learn much about the features, I did learn a bunch about the philosophy which was interesting. Also that was intentional since I knew I’d be late. I needed something I could jump into without it being cumulative. This fit the bill!

Leave a Reply

Your email address will not be published. Required fields are marked *