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

Dawid Kurzyniec dawidk@mathcs.emory.edu
Fri, 9 Jan 2004 04:05:29 -0500


> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Luke Blanshard
> Sent: Thursday, January 08, 2004 10:40 PM
> To: dl@altair.cs.oswego.edu
> Cc: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Re: AtomicInteger and 
> AtomicLong should implement Number
> 
> 
> dl@cs.oswego.edu wrote:
> 
> >... But the reasons at this point boil down to taste. We need a 
> >knockdown argument one way or the other about this to make a 
> confident 
> >decision. Anyone got one?
> >  
> >
> Not I.  But I would point out that this entire thread is 
> predicated on 
> taste: the idea that AtomicInteger must be a kind of Integer 
> because of 
> its name.  I doubt that making it a Number would alleviate that 
> particular confusion.
> 
> I don't think you will find a "knockdown argument" for this 
> issue.  You 
> could plausibly go either way with this.  However, I suspect that you 
> have more support on this list than you have seen expressed for your 
> collective inclination to not conflate AtomicInteger and 
> AtomicLong with 
> Number.  Just because it's possible doesn't mean it's a good API.

I agree. People tend to keep quiet when they agree with EG and when it
stands its ground :)

Anyway, I must say I am surprised by the heat of the argument over such
a minor detail, which does not even belong to a concurrency API. People
somehow survived 8 years of Java, writing a quality software, without
autoboxing; apparently, it is not so critical part of the Java
technology and it was not the most wanted improvement. Given that the
proposed "AtomicX" modification would have much smaller syntactic impact
than autoboxing, I conclude that the claims that it is so badly needed
by the community are rather exaggerated. Also, as I said before, I would
be careful estimating usefulness of "AtomicX" classes at the layers of
business logic and presentation, which have to do with number
conversion. However, once the classes inherit from Number, we will be
stuck with that forever (it is always easier to add something later than
to remove it).

And when one has a "gut feeling" (but lacks a "knockdown argument") that
something should be done differently in the JSR 166 (as happened to me
many times, and is still happening sometimes), one also has to put on a
weight the "gut feeling" of people who spent last X years of their lives
designing and refining this API and gaining user feedback.

Regards,
Dawid Kurzyniec