Re: Why are methods of java.util.concurrent classes final?
Eric Sosman wrote:
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?
More to the point, what makes Object#equals() special?
Your question presupposes that non-final is normal and final the exception.
It should be the other way around.
There were compelling reasons (at least as conceived by the designers of the
Object class) to allow overrides of equals() despite the "egregious violation
of every principle we all hold dear," and the Javadocs are therefore filled
with all kinds of warnings and caveats to make sure that equals() is
consistent with hashCode(), that it matches the rules laid down by any
compareTo() in the class, that it should be cognate to toString(), that it be
symmetric, reflexive and transitive, I mean, come on! Look how much work and
risk and trouble the overridability of equals() entails!
Much safer and easier to keep methods, yea, even classes final and avoid the
whole mishmosh unless there is a compelling, dare I say overriding, reason to
make them non-final.
--
Lew