[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number

Larry Riedel larryr@saturn.sdsu.edu
5 Jan 2004 19:11:02 -0000


> the original argument went:
> 
> AtomicInteger is a kind of Integer
> Integer is a kind of Number
> => AtomicInteger is a kind of Number
> eg. class AtomicInteger extends/implements Number { ... }
> 
> where the more direct inference would simply be that:
>  class AtomicInteger extends Integer
> (and thereby is also a Number).

The reason I avoid even suggesting "extend"ing from a class is that
Java has not traditionally provided support for multiple inheritance
of implemention, which has lead to using naming conventions and/or
runtime gyrations to produce an object which looks and behaves as
though its class Q had inherited implemention from class X and class
Y, but which, from the point of view of the language/compiler, is
unrelated to class X or class Y.  As an application programmer I
still think of that object as being "an X" or "a kind of X" because
that is the intent, even though Java says it is neither.  If Number
was an interface, and Integer was an interface, then I /would/ think
it might be nice to see "interface AtomicInteger extends Integer".

I myself often wind up doing what I think was suggested elsewhere
in this thread, which is to just take the method signature of a
class and copy it into an interface ("INumber" or whatever) and have
the class implement that interface, if I am at liberty to do that.
This also helps me avoid the problem of having to answer questions
from maintenance programmers and users of an API like "in class Q,
why do you inherit from class X and delegate to objects of class Y
and class Z rather than inheriting from class Y and delegating to
objects of class X and class Z, or inheriting from class Z ...",
and having to say "Java only lets me inherit from one, so I had to
pick one, so I rolled the dice and it came up 'X'".  That does not
go over too well when someone says "but I have a bunch of code which
expects to receive a Y object, and your object is an X object, even
though it has all the methods of a Y and behaves just like a Y".
I would rather just forget the class "extend"ing altogether.

If I just avoid "extend"ing classes, and either going with all
interfaces or naming conventions (a J2EE approach) it makes
this kind of thing less confusing, because at least it is lame in
a consistent rather than arbitrary way.  But when a third-party
library like the JDK says "Number is a class, Integer is a class
(which extends Number), AtomicInteger is a class (which wraps an
Integer), but an AtomicInteger is not an Integer or Number", I guess
it is time to go write more wrappers to get around JDK obliqueness.
I would like to mention that I think the people in the JCP/JSR
groups are doing an outstanding job of making the best new stuff,
given the obscenely ugly JDK 1.[01] and Java language legacy, and
it looks to me like most of the inelegances in JSR-166 are a result
of that legacy, not because of poor working group decision making.


Larry