JEP update: Value Objects

John Rose john.r.rose at oracle.com
Tue Nov 30 06:53:56 UTC 2021


Two points from me for the record:

1. I re-read the JEP draft now titled Value Objects, and liked everything I saw, including the new/old term “Value” replacing “Pure” and “Inline”.

2. In your mail, and in the companion JEP draft titled Primitive Objects, you refer to “primitive classes” and their objects.  It would make our deliberations simpler, IMO, if we were to title this less prescriptively as “Primitives” or “Primitive Types” or “Primitive Types and Values”, rather than “Primitive Classes”, because (a) there’s no logical need for the new things to be classes, and (b) it might actually be helpful for them *not* to be, in the end, after deliberation.  Putting the word “classes” in the title presupposes an answer to deliberations that have not yet been concluded.

People should note that the term “class” and “object” is only loosely bound to the term “primitive” in most of our designs, since (of course) today no primitives at all are either defined by classes or have objects.  They have corresponding reference or box classes and objects, to be precise.  Today a primitive type “has a class” but it is not the case that it “is a class”.  We could choose to preserve this state of affairs instead of fixing it by making “classes everywhere”; it makes some dependent choices easier to make.  As you know, one possible bridge to the future is, “Today all types are a disjoint union of primitives, classes, and interfaces, and tomorrow the same will be true, with all three possessing class-like declarations.”

What about objects, shouldn’t primitives at least be objects?  Well, interfaces don’t directly have objects today; they have objects of implementing classes.  Likewise, primitives need never have objects directly, as long as they have objects which properly relate to them—their boxes.  Boxes-boxes-everywhere certainly has its downsides, include pedagogical downsides, but that doesn’t make it a non-starter.

Instead, if we choose to use the terms “primitive class” and “primitive object” as exact counterparts to “reference class” and “reference object”, as your chart suggests, Dan, we will have to account for the duplication and/or ad hoc division of various attributions of classes and objects between the “primitive  class” and its corresponding “reference class” (e.g., int.ref, Point.ref).  I think a good leading question is, “if a primitive is a class, and its reference type is also a class, which of its methods are situated on the primitive class, and which are situated on the reference class?”  I would suggest that we be more sure we want to have two classes per primitive, or only-a-primitive-class per primitive, before we presuppose a decision by putting the word “Classes” in the title of JEP 402.

> On Nov 29, 2021, at 4:09 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> I've been exploring possible terminology for "Bucket 2" classes, the ones that lack identity but require reference type semantics.
> 
> Proposal: *value classes*, instances of which are *value objects*
> 
> The term "value" is meant to suggest an entity that doesn't rely on mutation, uniqueness of instances, or other features that come with identity. A value object with certain field values is the same (per ==), now and always, as every "other" value object with those field values.
> 
> (A value object is *not* necessarily immutable all the way down, because its fields can refer to identity objects. If programmers want clean immutable semantics, they shouldn't write code (like 'equals') that depends on these identity objects' mutable state. But I think the "value" term is still reasonable.)
> 
> This feels like it may be an intuitive way to talk about identity without resorting to something verbose and negative like "non-identity".
> 
> If you've been following along all this time, there's potential for confusion: a "value class" has little to do with a "primitive value type", as we've used the term in JEP 401. We're thinking the latter can just become "primitive type", leading to the following two-axis interpretation of the Valhalla features:
> 
> ---------------------------------------------------------------------------------------------
> Value class reference type (B2 & B3.ref)	| Identity class type (B1)
> ---------------------------------------------------------------------------------------------
> Value class primitive type (B3)			|
> ---------------------------------------------------------------------------------------------
> 
> Columns: value class vs. identity class. Rows: reference type vs. primitive type. (Avoid "value type", which may not mean what you think it means.)
> 
> Fortunately, the renaming exercise is just a problem for those of us who have been closely involved in the project. Everybody else will approach this grid with fresh eyes.
> 
> (Another old term that I am still finding useful, perhaps in a slightly different way: "inline", describing any JVM implementation strategy that encodes value objects directly as a sequence of field values.)
> 
> Here's a new JEP draft that incorporates this terminology and sets us up to deliver Bucket 2 classes, potentially as a separate feature from Bucket 3:
> 
> https://bugs.openjdk.java.net/browse/JDK-8277163
> 
> Much of JEP 401 ends up here; a revised JEP 401 would just talk about primitive classes and types as a special kind of of value class.
> 



More information about the valhalla-spec-observers mailing list