Re: Why are methods of java.util.concurrent classes final?
Lew wrote:
Eric Sosman wrote:
Lew wrote:
Eric Sosman wrote:
Have we arrived at a circularity? "The methods of
AtomicInteger are final because they are final."
Only if you remove intent. Don't remove intent.
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.
It's more than that. The designers chose to prevent overrides as a
matter of policy.
Oh, I see. It's not that "The methods of AtomicInteger are
final because they are final," but "The methods of AtomicInteger
are final because they are final *as a matter of policy*."
At last (finally?) I feel enlightened (endarkened?).
You can trivialize the discussion by eliding the relevant parts, but it
doesn't change the facts.
In all seriousness, and with no intention of trivializing
anything or demeaning anyone or mocking anybody else: I have not
yet seen *any* explanation for the finality of AtomicInteger
methods other than "That's the way it is."
Saying that "The designers made a decision" is not an
explanation, only a description of an outcome. I think we can
take it as read that the O.P. understands the outcome, and the
immediate cause thereof (to wit: "The designers made a decision"),
but is curious about what might have motivated the decision,
which from his viewpoint seems capricious.
The only -- only! -- argument I've seen in this thread that
might -- might! -- cast light on their decision is that the
designers feared an override could violate the semantics of the
AtomicInteger class. I find the argument unconvincing because
plenty of other classes allow overrides despite the harm that
might result from evil or sloppy code. You, of course, are
free to find such arguments not only convincing but compelling --
but please don't belittle those who aren't fooled^H^H^H^H^H^H^H
similarly convinced and compelled.
--
Eric Sosman
esosman@ieee-dot-org.invalid