Introduction

A number of people describe Valhalla recently as being "primarily about performance".  While it is understandable why people might come to that conclusion -- many of the motivations for Valhalla are, in fact, rooted in performance considerations -- this characterization misses something very important.  Yes, performance is an important part of the story -- but so are safety, abstraction, encapsulation, expressiveness, maintainability, and compatible library evolution.

...

Which is the real point -- that we need not force users to choose between abstraction/encapsulation/safety and performance.  We can have both.  Whether you call that "cheaper objects" or "richer primitives", the end result is the same.

2. Extend generics to allow abstraction over all types, including primitives, values, and even void

...

Generics are currently limited to abstracting only over reference types.  Sometimes this is merely a performance cost (one can always appeal to boxing), but in reality this not only increases the cost, but decreases the expressiveness, of libraries.

...

Which is to say, again, just at the data-abstraction layer instead of the data-modeling layer: we need not force users to choose between abstraction/encapsulation/safety and performance.

3. Enable existing libraries -- especially the JDK -- to compatibly evolve to fully take advantage of these features

...

The breadth and quality of Java libraries is one of the core assets of the Java ecosystem.  We don't want people to have to replace their libraries to migrate to a value-ful world; nor do we want existing libraries to be "frozen in time." (Imagine if we did lambdas and streams, but didn't do default methods, that allowed the Collection classes to evolve to take advantage of them -- Collections would have instantly looked ten years older.) There should be a straightforward path to extending existing libraries -- especially core JDK libraries -- to supporting values and enhanced generics, in a way that makes them "look built in".  This may require additional linguistic tools to allow libraries to evolve while providing compatibility with older clients and subclasses that have not yet migrated.

...