[concurrency-interest] weakCompareAndSet in atomics - incompatibleclass change?

David Holmes dcholmes at optusnet.com.au
Sun Mar 4 16:54:53 EST 2007


Dawid,

> Question: isn't adding a final method to a non-final class an
> incompatible class change? It breaks subclasses containing a method with
> the same signature. What's the official view on this?

It is an incompatabilty, so you have to weigh the potential gain against the
potential damage. But changes like this are quite common when going from one
major rev to another.

The possibility that someone had added a weakCompareAndSet method to an
atomics subclass seemed remote.

> This is what happened with Atomic* classes: in 6.0, weakCompareAndSet()
> method was added. As a result, the backport-util-concurrent optimized
> for 5.0, in which the "backport" atomics extend native atomics, does not
> work on 6.0. (I always thought that Atomic* classes should have been
> made final :P )

Having the classes be non-final has some minor advantages for reducing
memory use in some cases eg defining a node class that IS-A
AtomicReferenceField.

I'm afraid you'll need a modified version to work on 6.0 - though that is
the backport adding on 6.0?

David Holmes



More information about the Concurrency-interest mailing list