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

Gregg Wonderly gregg.wonderly@pobox.com
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 
>>like.  

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
>>classes).

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
>>concrete subclasses.

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 
put forward.

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!

Gregg