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

Larry Riedel larryr@saturn.sdsu.edu
14 Jan 2004 03:51:49 -0000

> I have existing code that has the following logic in it.
> 	if( NumberImpl1.equals(NumberImpl2) ) {
> 		...
> 	}
> How am I going to reuse this code without doing

I think in any specific case it is not going to a big problem, just one
more little thing which makes using Java seem to be a pain in the ass
for no good reason.  I think C++ was the same way, CORBA... where the
language/framework developers had such myopia and fixation on specific
semantic minutiae of particular situations to not see that really the
only overall viable solution is for everything to be transparently simple
and utterly, pervasively, unrelentingly consistent, leaving very few API
design decisions to be made on a case by case basis since the need for
transparency and universal consistency take away all the flexibility.

>From that point of view, Java was DOA, obscenely convoluted and inconsistent
from the beginning; but Java was cross-platform and free to use, and
had static type checking, garbage collection, fairly simple mostly
working degenerate multiprocessing support, and a commitment to provide
implementations for a rich set of officially sanctioned APIs.  I think those
things still set Java apart, regardless of how crappy it otherwise is,
although it seems to me there is a pretty good chance that C# and dotNET
will eventually supplant Java because they provide those good things in what
I think is a more simple, consistent, intuitive way.  For example I like
the System.Threading.Interlocked.CompareExchange stuff in dotNET because it
seems to come closer to providing just what it needs to provide related to
atomicity (test-and-set); no less, and especially no more.