How common are Reference-default classes?

Stephen Colebourne scolebourne at
Fri Dec 20 11:34:48 UTC 2019

Recent spec-experts discussion identifies inline-default and
reference-default types [1]. I think its a great point to consider,
and wanted to add my own data points on reference-default.

In OpenGamma code, including the OSS Strata [2], we have almost no
need for object identity at all. The few uses of synchronized are on
methods or on a `new Object()` instance, and are therefore easy to
migrate. The 4 uses of IdentityHashMap look easily solvable in other
ways. And we avoid subclassing, using interfaces for hierarchies
instead. As such, it seems to me that pretty much every instantiable
class could be a Reference-default inline class (certainly all the
beans could be, I suspect the classes representing functionality would
gain little). The potential gains seem large as the change would
affect the whole system, even if only 10% of cases actually ended up
being flattened by the JVM.

I suspect there are plenty of other systems in the wild that would be
in the same situation wrt identity. Which suggests to me that
reference-default inline classes have the potential to be very common,
much more common than inline-default ones (unless I'm missing
something obvious...). ie. there are more use cases for identityless
classes than true value types.

Given the data above, I think option 4 being discussed is worthy of
serious consideration. If the underlying inline type is not visible or
needed in most cases (ie. the ones described above), then the syntax
`Foo.inline` isn't such a problem (or perhaps the underlying pure
inline type is a JVM-level thing not visible to the language). For
those use cases like Point or LocalDate where the inline type is
actually needed and meaningful it could then be opt-in, where I still
like the syntax of `point` vs `Point`, or `localDate` vs `LocalDate`.
And those use cases may be infrequent enough that option 1 is
sufficient. (Overall, I suspect that I am arguing here for two
distinct features from Valhalla - "light" (identityless) classes and
"inline" classes. More work no doubt, but feels like it could be a
better outcome and more consistent with the large body of existing
Java code.)



More information about the valhalla-dev mailing list