The substituability test is breaking the encapsulation

forax at forax at
Mon Feb 25 21:28:03 UTC 2019

----- Mail original -----
> De: "John Rose" <john.r.rose at>
> À: "Brian Goetz" <brian.goetz at>
> Cc: "Remi Forax" <forax at>, "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Lundi 25 Février 2019 21:37:00
> Objet: Re: The substituability test is breaking the encapsulation

> On Feb 25, 2019, at 6:32 AM, Brian Goetz <brian.goetz at> wrote:
>>>> To pick up on John’s note from v-dev over the weekend, value-objects are more
>> easily _forgeable_ than identity-objects.  There are infinitely many possible
>> java.lang.Integers, because of the unique-per-instance identity; there are only
>> finitely many instances of
>>    value class IntWrapper { public int i; }
>> and, given access to the constructor, you can construct them all, and readily
>> stamp out whatever instance you like, and it is just as good as all other
>> instances with that state.
> My current favorite metaphor for explaining the difference
> between value* objects and reference* objects is the one
> you coined, Brian, of the little band placed around the infant's
> wrist just after birth.  Similarly the JVM adds such a unique
> extra identity* (what else do you call it?) to every Integer but
> not to any int.  Values are not values because they have
> something different from objects, but because they don't
> have the wristband; you can't tell them apart anymore,
> compared to objects which always carry their little wristband
> around.  (Metaphor failures:  We don't use infant wristbands
> to *tell infants apart*.  And the infant eventually loses the
> wristband.  Tattoo?  Let's not; besides those are forgeable.
> Regardless, the wristband is helpful.)
> So if an implementor wants every new value to be not-same*
> to every other new value, the implementor of the value* class
> can just add a wristband.  That is:
>>    value class UnforgeableIntWrapper {
>>      public int i;
>>      private Object wristband = new Object();  }
> And done, I hope.
> Does the JVM have anything to add here?  I don't think so.
> If we were to create unforgeable value objects as a third
> or fourth kind of type, this is the implementation we'd use.
> So encapsulation, controlled by user choice, provides adequate
> control over this corner case in op== semantics.

it's unforgeable but you can still guess the content of 'i' using a timing attack ? no ? 

> — John


More information about the valhalla-spec-observers mailing list