[concurrency-interest] Should I avoid compareAndSet with value-based classes?

Alex Otenko oleksandr.otenko at gmail.com
Mon Jul 10 06:23:19 EDT 2017


Thanks, that makes sense. The evasive language of the spec can get interpreted by some to mean that it is not guaranteed, so perhaps some clarification needs to be signed off - like, if unboxing is not required, then it should behave like no unboxing happened.


Alex


> On 10 Jul 2017, at 11:06, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 07/10/2017 12:02 PM, Alex Otenko wrote:
>> Thanks, this is very useful.
>> 
>> What about
>> 
>> Runnable r1 = () -> {};
>> Runnable r2 = r1;
>> assert r1 == r2;
>> 
>> should we expect a bombshell here? Clearly, autoboxing/unboxing is allowed to happen, if, say, r1 and r2 were Integers, but which side of the surprising behaviour will the JVM choose?
> 
> I think the answer is the same as with Integers, if you rephrase your example
> with them:
> 
>  Integer i1 = 4242;
>  Integer i2 = i1;   // this is not autoboxing anymore, this is reference store
>  assert (i1 == i2); // would you expect this to fail?
> 
> Similarly, the key part is here:
>  Runnable r2 = r1;  // this is not a lambda-expression, this is reference store
> 
> Thanks,
> -Aleksey
> 



More information about the Concurrency-interest mailing list