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

Larry Riedel larryr@saturn.sdsu.edu
15 Jan 2004 20:49:07 -0000

> I contend that the information about these classes that is
> most important is the numeric value inside.


> I really think it is a step sideways (almost backwards) to add
> atomic integral value access and not have a value based comparison
> visible in the objects implementation.


> mutability is an issue with each and every Java Object created
> or used by Java programmers.  It is not a new issue and it is not
> going to go away.


> You are still supposing that every single time these values are
> reference by a call to equals that they are going to be actively
> engaged by code that is changing the values.  I can not see this
> being a good argument.


> I create interfaces that describe what I need to do, and then write
> the low level classes that provide the how.  This makes it much
> more likely that I can switch out the hardware.  I even study the
> implementation details of multiple pieces of hardware that might
> have to be used at a later date, and engineer the interface with the
> commonalities of all the hardware in mind.

I feel like the biggest ironies are that (1) what I wanted was an
interface to a common hardware facility, atomic compare-and-increment,
test-and-set, etc, not something which, if I want to use it for the
purpose of application efficiency/performance optimization, asks
me to care whether I should or shouldnt have an application which
makes assumptions about the state of a object which is not immutable,
and (2) these hardware facilities I am trying to use are themselves
oriented around NUMERIC VALUES, and yet there seems to be a feeling that
efficient atomic access to numeric values is somehow a marginal/fringe
use case.

Speaking of marginalized, it seems to me the walls are closing in on Java
since Python (and even VB.NET) is vastly more productive for the most common
applications, and support has crystallized with C and C++ to make the
barrier pretty low to use them to put together applications which need to be
very lean/fast or talk to hardware, and still be robust.  I think Java has a
history of making the cost of efficiency/performance too high to make it a
viable choice for a high efficiency/performance application, but it is too
arbitrarily cumbersome for making simple things simple.

It seemed to me like the changes for JDK 1.5 could make Java come closer
to a high efficiency/performance application development solution, but
it looks like maybe even the stuff in JDK 1.5 is going to make the
reality of making a high efficiency/performance Java application still
a little too far off because the JDK continues to put a lot of goopy
stuff (eg AtomicInteger) between the application and what it wants to
do.  But anyway independent of JSR-166, if objects can still only be
resurrected once, I think there is pretty much no real world hope to
develop efficient applications in Java, because the mechanisms are still
not there for effectively recycling garbage objects, and the core JDK
APIs are treacherously improvident about creating objects.