[concurrency-interest] Should I avoid compareAndSet with value-based classes?
oleksandr.otenko at gmail.com
Tue Jul 11 14:15:39 EDT 2017
> On 11 Jul 2017, at 18:30, Aleksey Shipilev <shade at redhat.com> wrote:
> I think "value-based class" language is provisional for "do not rely on
> identity, even if it is defined for the objects you will be getting". Integer,
> as you say, have already leaked the identity in public, and we are done there,
> the guy is disqualified.
> In this parlance, saying "Instant is like primitive/Integer" is far worse
> language than actually spelling out the "unknown identity" rules with
Spelling out “unknown identity” is like “we don’t really know what we are doing”.
There is no similar problem with Integer, but not because of “public constructors”. It is because there is a clear separation between boxed context (Integer a), and unboxed context (int a).
The reference Remi quoted a few days ago is also more sensible than what we are talking about here. Even though I don’t like the language, clearly there’s a notion of boxing-unboxing instructions. Clearly, there are meant to be rules about where those instructions can and cannot go. Those rules determine the meaning of “==“.
I will expect the variable that is not assigned a different value to retain its “identity” within the lexical scope of the value’s visibility.
I will expect there will be no heisen-boxing - replacing unboxed values with boxed values, when the value is still observed in the lexical scope.
> "value-based class" text. Having these rules spelled out eases switching them to
> real value types, with appropriate spec changes. But, it does not give a blanket
> approval for doing so, it just minimizes the damage.
> I understand one could claim "JVM is allowed to ignore identity for value-based
> classes, because it is claimed to be unpredictable anyway", and probably lawyer
> up to say it is spec-legal. Although it would be fun to see the defense where
> Javadoc trumps the core JLS.
> Still, I think the interpretation of "identity stays unknown, but still behaves
> like an object" is saner from quality of implementation, principle of least
> astonishment, "don't break Java" standpoints.
> How will Valhalla deal with these problems, we shall see. My bet is on
> value-type-specific comparisons (which should catch CAS in its wake), plus
> boxing where the references are needed (which would capitalize on what we
> learned to love about Java's primitives).
> I think this CAS example is interesting to discuss in valhalla-dev@, where it
> actually matters, not here.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest