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

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 05 Jan 2004 08:47:11 -0600

David Holmes wrote:

>>I recognize that this would not be a backward compatible change.  I
>>wonder how many people would have extended Number...
> Ignoring issues of whether Number should have been an interface, and
> whether all Numbers must be immutable, exactly why do you think
> AtomicInteger and AtomicLong should be Numbers?

I have numerous applications in multithreaded environments where 
integers and floating point numbers are used to track the values of 
external entities.  These applications use XML and other descriptive 
mechanisms to create forumla to relate these values in useful ways 
(volume/unit-time etc.).  What I see happening is that users of my 
applications will look at these classes as useful ways to accomidate 
synchronized programming involving calculations with numeric values.  I 
can currently use the 'is a Number' test to accomodate a wide range of 
numeric values in the low level evaluation code.

If I have to add support for these classes, I will not have a generic 
reference type to make the processing of these values easily accomodated.

It appears to me that these two classes are used largely for counting 
semaphore type operations.  My software is used in such ways that the 
statistics present in these values would be very useful for status 
monitoring of systems that use these classes.

> AtomicInteger and AtomicLong are not numeric types, ala Integer, Long,
> Float, BigDecimal etc, but simply utility classes to access int or
> long values in an atomic way.

But they contain values that might be referenced in such a way, and 
having to have two references to the same value by doing

	AtomicInteger i1 = new AtomicInteger(0);
	... and later...
	externalRef = new Integer( i1.get() );

is not going to produce high quality applications.

Think about someone instrumenting their application (perhaps with JMX) 
and how effectively they could extract statistics about all the classes 
in this JSR to 'see' where resource contention is occuring because of 
synchronization issues.

If it seems late to change java.lang.Number, then let's think about 
replicating that class as an interface somewhere in the package tree
so that there is a greater opportunity to reduce the total number of 
class names that an application has to be aware of to 'see' into 
applications written with these classes.

In particular, remote applications (Jini, JMX etc), beg us all to 
consider just how different we should make the interface to any class we 
would use in these environments.

I would imagine a lot of people taking these classes and using them in 
unimaginable ways because everyone will see the word Atomic in the name 
and think wow this will keep be from spewing 'synchronized' all over my 
code.  Then, others of the numerically minded type will see 'Integer' 
and 'Long', and say wow, "Number"s this will let me have lots of 
calculating threads that can just bang on these values and I won't have 
to worry about 'synchronized'.

Think big, design with a simple API...