Re: Why are methods of java.util.concurrent classes final?

From:

Eric Sosman <esosman@ieee-dot-org.invalid>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 24 Jun 2009 21:48:53 -0400

Message-ID:

<h1ul67$rt7$1@news.eternal-september.org>

Lew wrote:

Eric Sosman wrote:

Lew wrote:

tan wrote:

If the intention behind final declarations was just to ensure the
atomicity of the atomic operations, it could also have been done by
not giving access to the underlying fields to outside packages. Or, am
I missing something here?

You are.

The access to the "underlying fields" is already restricted, so if a
subclass were to access them it would be through superclass methods.

However, if those methods could be overridden, it would be possible
to do so in a non-thread-safe manner. No access to "underlying
fields" is needed for that. It would be possible to break the
semantics of the superclass, even for single-threaded use. There's
no way the writer(s) of AtomicInteger can prevent that save by
preventing the methods from being overridden.

The explanation seems unsatisfactory, because it applies to *any*
overridable method of *any* class.

public boolean equals(Object obj) { return true; }

... is an egregious violation of every principle we all hold dear,
yet Java does not prevent someone from writing the obscenity. So,
what makes AtomicInteger special?

When the purpose of a method is to be overridden, one documents the
risks and accepts the consequences. AtomicInteger is not intended for
such usage.

Have we arrived at a circularity? "The methods of
AtomicInteger are final because they are final."

Perhaps that really *is* the only explanation: The
designers of the class thought `final' would be a good
idea, so they threw it in. It seems to me that the O.P.
has a use case that cries out for non-final methods -- so
maybe we're left with an inherent conflict between "The
class designers were insufficiently imaginative" and "The
O.P. ought not poke his twitchy nose into Things Man Was
Not Meant To Know." In other words, "That's the way it
is, Wednesday, June 24, 2009."

--
Eric Sosman
esosman@ieee-dot-org.invalid