Welcome to valhalla-spec-experts

[Brian Goetz]

Welcome to valhalla-spec-experts!  This list is an OpenJDK-hosted 
precursor to (hopefully) an eventual JCP Expert Group.  The initial 
membership includes representation from Oracle, IBM, JetBrains, Red Hat, 
and Google, as well as individuals from the OpenJDK and Scala communities.

Project Valhalla echoes the approach of Project Lambda, which started 
with a single, simple-sounding idea (add lambda expressions to the Java 
language) -- but the consequences of adding this "simple feature" were 
anything but simple, sending ripples throughout the JVM, language, and 
libraries.  In addition to the many technical challenges, the overriding 
stewardship challenge was to find the natural scope for these ripples; 
damping them too aggressively would would result in a key feature 
looking "nailed onto the side", but at the same time, we needed to avoid 
getting too carried away by the excitement of adding cool new features 
"because we can" -- because otherwise the project would have exceeded 
its delivery and complexity budgets.

Project Valhalla's core feature is adding user-definable value types to 
the JVM type system 
(http://cr.openjdk.java.net/~jrose/values/values-0.html).  The 
consequences of adding this simple-sounding feature, however, are deep 
and far-ranging, rippling into the language type system, generics, the 
inheritance model, the bytecode set, and the core library APIs.

To illustrate: if we had value types, but couldn't instantiate generic 
types with a value (i.e., no ArrayList<Complex> without appealing to 
boxing), this would be pretty useless; if boxing were a good enough 
solution here, we wouldn't even have bothered with value types.  So 
pulling on the "value types" string, we get the need to generify over 
both references and values.  And pulling on that string some more, we 
discover that our existing Collections library has methods (e.g., 
Map.get()) which bake in assumptions that "T is always an Object", 
leading us to a reexamination of these core APIs.  Which in turn leads 
us to exploring additional features for API migration, which becomes 
more relevant as our core APIs approach being old enough to drink.

Similarly, as we add value types, there are some core classes (e.g., 
LocalDateTime, Optional) which always wanted to be values, and would 
benefit tremendously from being so.  It therefore becomes desirable to 
migrate these to be value types, in a way that's both binary and source 
compatible with existing clients and subclasses?

We've been exploring the bounds of this problem space for more than a 
year now, and we think we're approaching a reasonable understanding of 
the scope and breadth of the various design tradeoffs.

Over the next few weeks, I'm going to pick some initial issues for 
discussion and try to frame them so that their overlap with other 
aspects is minimized.  Stay tuned!