How common are Reference-default classes?

[Brian Goetz]

Summary: "Flattening is very cool, but if there were a middle ground 
where I could get some non-flattening benefits by giving up identity, 
I'd be a customer for that, since I don't use identity much anyway."

Which is a good reminder; of course, this depends on what benefits you 
could get in the inline-but-not-flat cases.

(On the other hand, the OpenGamma codebase is what I would call a fairly 
"disciplined" and "actively curated" codebase; you started out with a 
set of API design principles and stuck to them fairly consistently, and 
when you make changes in style, do so uniformly. Which is very good, of 
course, but not necessarily all that common, so I'll just log the 
warning that this might not be ideal the codebase to extrapolate from.)

> 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.)
>
> thanks
> Stephen
>
> [1] http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-December/001177.html
> [2] https://github.com/OpenGamma/Strata