[concurrency-interest] Re: AtomicInteger and AtomicLong should
Thu, 08 Jan 2004 22:57:12 -0600
Doug Lea wrote:
> We need a
> knockdown argument one way or the other about this to make a confident
> decision. Anyone got one?
I'll comment on some of the EG discussion, but I don't think I have any
new/different to really add. I think this would be a good thing to do.
I don't know that it is the 'right' thing to do, because I can't see
into the future. But, my gut feeling is that there are enough things
about this change, for my use of these classes, that it would be valuable.
>>I don't think a lot of thought went into Number, so we're basically
>>looking for meaning in chicken entrails. It is currently the case that
>>all J2SE subclasses of Number are immutable, but Number has a (public)
>>default parameterless constructor (almost certainly accidental, and
>>undocumented to boot), so you can make your own mutable subclass if you
Since Number was in from the beginning, and Java was a pot of stew over
an open flame between the 0.9 and the 1.0 release, I wouldn't expect
Number to be much more than a guess at what would be needed.
>>I don't think we'd be sacrificing any great invariant by having
>>AtomicInteger extend Number, but just because you can do a thing doesn't
>>mean you should. I think the question is, does having AtomicInteger
>>(and pals) extend Number foster a programming style that we like, or one
>>that we dislike? Does it have any compelling performance advantages? I
>>think the answers are "one that we dislike" and "no."
Being the usage police is an interesting job. Sun has tried with the
release of many technologies, based on java, to direct new markets.
They wanted Java to be used in applets in 1.0. But, AWT sucked and
caused java programs to crash or lock up the computer. All the non-GUI
code was fairly usable, so suddenly, Java went server side where it has
been predominent since. But, slowly, it is floating into the desktop
again. There are similar stories for Jini in devices, etc. I don't
think you can, or should try to be looking at what you can keep from
happening. I, personally find it more exciting to see what I can enable.
>> Encouraging use of AtomicInteger as a mutable replacement for
>>Integer is not a good thing in my view. Further the only way to use
>>numbers in a "generic" fashion is to promote everything to double and
>>that's not something I'd want to encourage. When/if-ever there is a
>>more complete numeric type hierarchy in Java we can slot in the atomic
>>classes (though that would also suggest we provide atomic float/double
In the world of computer science, there have been predominately 2
classes of 'real' numbers. Integer and Floating Point. There are lots
of sizes and repesentations for each. In the Java language, what the
Number classes present to the world is what will be there for a long
time to come. Why? Because thats what non-numerical analysis
programmers are going to use for simple numeric values. They don't know
better or different.
Of course, I am still guessing, but this is what I see happening. This
part of the language is just too imbedded in the implementation details
to really be reworked anytime soon. And, I don't think that having
these classes extend Number complicates, inhibits or otherwise makes
them any uglier than they already are. I think it helps them have a
more Java feel and less of a limited utility class feel.
>>Regardless of whether the Number class javadoc comment can be changed,
>>it's a bad idea for any class to extend an abstract class that takes the
>>trouble to list its concrete subclasses in its class javadoc comment,
>>especially if the extension is fundamentally different from the listed
This is a documentation issue, not a technical reason to not subclass it
seems to me.
>>Byte, Double, Float, Integer, Long, and Short don't bother to document
>>their immutability at all, so the absence of such documentation on
>>Number doesn't imply mutability. (BigDecimal and BigInteger correctly
>>say "immutable" right up front, thanks to Josh.)
Whether or not a numeric value is immutable, it can still be used in
expressions and in diagnostic messages, as an argument to a method etc.
A big thrust of jdk1.5 is programmer friendliness. Things are supposed
to be easier to do. Having to spray
new Integer( atomicIntForSomeUse.get() )
all over the place, doesn't make the job any easier.
Syntactic sugar is not what this is. This is programming hassle. I
could, in fact create a whole new package of classes that provide the
atomic operations and which inherit from Number. The question is should
everyone that needs this, have to do it. Should I have to create a
java.net project so that I can share this code and champion its use,
then start a JSR that will be added to a JDK in another 2-3 years etc.
I don't think that all of that hassel is any better than the arguments
On a related note, the more I look at these classes the more I think it
is a mistake not to qualify the get() method as getInt() and getLong()
so that the reader knows the size of what they are retrieving. If they
are changed to extend Number, I would suggest that get() be renamed to
intValue() and longValue() respectfully.
There are clearly a lot of emotions mixed up in all the discussion here.
Hopefully, the right decision can be made. And, I am not suggesting
that I know what's right. I'm saying that whichever way is decided, we
all get to live with for the next several years. Hopefully that will be
the right decision!