[concurrency-interest] Re: AtomicInteger and AtomicLong should
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
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...