Welcome to valhalla-spec-experts
brian.goetz at oracle.com
Mon Dec 7 20:55:51 UTC 2015
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
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!
More information about the valhalla-spec-experts