[concurrency-interest] Should I avoid compareAndSet with value-based classes?
vitalyd at gmail.com
Fri Jul 7 13:39:28 EDT 2017
I've skimmed this thread, so maybe missing something, but I agree with Kirk
This needs to be solved at the type system level, not runtime exceptions
(nevermind the compatibility story). A ValueBased class, IMO, is at most a
lint - I have a hard time imagining how those classes can be converted to
real VT when those exist. No amount of javadoc will avoid breakage.
Without this being in the type system proper and thus making a compiler
fail a build if misused. == needs to stay as is, and any code today that
uses == must be changed to only work on T=reference type when VT is
introduced and must refuse compilation (and verification) if provided a VT.
How to enable CAS and the like for VT would be a separate matter.
On Fri, Jul 7, 2017 at 1:05 PM Kirk Pepperdine <kirk at kodewerk.com> wrote:
> > 3. The exception-throwing thing is IMO the healthy way to go IMO. I.e.
> throw some runtime exception when encountering an indentity-based operation
> on an instance of a value-based class. Hard to argue that "an exception
> should not be thrown here" given the clear warnings in the spec. My worry
> is mostly about coverage. Throwing exceptions in all cases where identity
> based operations are attempted would clearly be right, and healthy. But
> doing so only in some cases (and leaving some undefined behavior executing
> paths that don't throw exceptions) doesn't solve the problem [and may make
> things worse by encouraging false confidence]. Since no one *requires* us
> to throw an exception right now, JVM implementors will probably keep taking
> the lazy approach and not work hard on trying to achieve complete coverage.
> And since don't do it at all" is probably better/easier to verify than "do
> it in some places but not in others", we'll probably avoid it altogether
> for now. This *may* change when value-based optimizations materialize.
> I think I’d have to (violently) disagree with this. There is a reason no
> one requires you to throw an exception when expressing equality and that is
> because this is a guaranteed property in the runtime. Without it you lose a
> fundamental property of the runtime.
> — Kirk
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest