[concurrency-interest] Should I avoid compareAndSet with value-based classes?
Brian S O'Neill
bronee at gmail.com
Thu Jul 6 14:52:50 EDT 2017
Although it would be nice to have value-based classes truly supported,
because the java.time classes are defined as ordinary classes, they can
never change into becoming true value-based classes without breaking
compatibility. You can't just change the definition of instance equality
without completely breaking the language completely. Improper use of a
weak value-based class should at the very least trigger a compiler
warning, but a full runtime check is too extreme.
Consider how these checks are implemented by the compiler. Adding a
runtime check would be equivalent to making every == check, cas, etc
behave like a virtual method call. I wouldn't be terribly happy to see a
performance regression introduced in something so fundamental and used
Also consider problems resulting an exception thrown from the ==
operator. This isn't supposed to happen. Any piece of code which is
designed to be fault tolerant (via exception handling) is now broken,
because it assumed (correctly) that fundamental language design elements
On 2017-07-06 11:15 AM, Gil Tene wrote:
> David, the below is a (potentially good) argument for not allowing the
> creation of subclasses of Object that do not have well defined support
> identity, identity comparison, identity hashing, or synchronization,
> since Object supports all those, things that hold Object instances may
> very well make use of them.
> But that horse has long fled the barn. We can argue that value-based
> classes should not have been specified in Java 8. Or that the future
> value types should not be derived from Object. But the first case is
> already in the Java spec, and the second is likely coming (and is
> sneakily able to use the first as a precedent).
> For the "how should we specify things?" discussion, I'm actually
> squarely on the side of "things with no identity should never have been
> derived from Object" of this argument. E.g. I would advise other
> language specifications to avoid making the same mistake, either by not
> giving the base Object class identity to begin with, or by creating a
> separate orthogonal type hierarchy for value types and "value based"
> classes. However, I don't see a way to "fix" the mistake already made,
> and we have to deal with the language and the machine as spec'ed, not as
> we wish it were. And so does anyone writing code in the language.
> In the context of that reality, we are discussing what correct uses of
> those new "basterd children of Object" are. And since the basterds
> clearly have no identity, using any logic that relies on identity
> behavior in any way is wrong.
> Sent from my iPad
> On Jul 6, 2017, at 10:53 AM, Gil Tene <gil at azul.com
> <mailto:gil at azul.com>> wrote:
>> Hence my suggestion that identity-based operations on instances of
>> value-based classes should throw exceptions... Right now they silently
>> do unpredictable things, and should be avoided in any case (but harder
>> to know/find when you accidentally use them).
>> Sent from my iPad
>> On Jul 6, 2017, at 10:46 AM, Alex Otenko <oleksandr.otenko at gmail.com
>> <mailto:oleksandr.otenko at gmail.com>> wrote:
>>> Are they subclasses of Object or not? If they are not, no questions.
>>> If they are, someone still needs to explain how exactly the “identity
>>> based operations” can be avoided safely.
>>> List<j.u.Optional> is just a List underneath, and searching for an
>>> item may use “identity based operations”, whether you want it or not
>>> - depending on what implementation of List you happen to use.
More information about the Concurrency-interest