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

[tan]

Why are the methods of classes in java.util.concurrent package
declared as final?

For example in AtomicInteger:
public final int get();
public final void set(int newValue);

 

[Mark Space]

Why are the methods of classes in java.util.concurrent package
declared as final?

For example in AtomicInteger:
public final int get();
public final void set(int newValue);

Well, those two methods, I think so you can't over-ride the methods and
make an AtomicInteger non-atomic. Other methods, I'd have to see them
and think about it.

 

[Roedy Green]

Why are the methods of classes in java.util.concurrent package
declared as final?

IntelliJ likes to mark any methods not overridden as final. This is a
documentation aid, and helps the run time generate faster machine
code.

If you have the source, final is not really final, it just means,
final for now. You can always open it up later.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Never discourage anyone... who continually makes progress, no matter how slow.
~ Plato 428 BC died: 348 BC at age: 80

 

[Arne Vajhøj]

IntelliJ likes to mark any methods not overridden as final. This is a
documentation aid, and helps the run time generate faster machine
code.

It did 12-14 years ago.

Not today.

Just one of those myths that tend to live on.

Arne

 

[Lew]

It did 12-14 years ago.

Not today.

Just one of those myths that tend to live on.

It's a bad thing to have an IDE do that without you asking. If I don't mark a
method 'final', the fact that it is not yet overridden doesn't mean that it
should never be. I probably mean for that method to be overridden later on,
and I certainly mean for it to be overridable.

 

[tan]

All the non-inherited public methods are final except for toString(),
intValue(), longValue(), floatValue(), and doubleValue(), which are all
simple wrappers around calls to get().

I don't know the specific reason for the use of final. However, even if
they were not final, I would not override any of the get or set methods
unless I were going to override all of them, in which case I would
effectively have a new class. In order to work correctly they all have
to be implemented using the same underlying mechanism.

Patricia

Thanks to you all for all your explanations.

My specific requirement was to maintain some sort of statistics (e.g.
min, max, average) of values taken on by an AtomicInteger. I also
wanted to do this without modifying code to use another wrapper class.
My intention was to use aspectj to intercept AtomicInteger variable
initializations and inject an overridden class instead where I would
do these additional calculations before calling super class methods to
pass on the call to the real AtomicInteger class. This is however not
possible now because AtomicInteger methods are final.

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?

Since I did not have any other alternative, I have now created my own
wrapper classes around Java's Atomic... classes. The wrappers have the
exact same methods as the real Atomic... classes and contain an
instance of the real Atomic... class to do the job. I had no other
option but to go and modify my sources, but I maintained the same
class names so that I had to update only the import statements.

- tan

 

[Lew]

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.

 

[Joshua Cranmer]

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?

I happened to be poking around the VM optimizations a while back, and I
noticed that final methods do have special semantics with respect to
optimization (vtable calls are eliminated in these cases).

 

[Lew]

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.

 

[Eric Sosman]

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."

 

[Lew]

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.

 

[Eric Sosman]

Only if you remove intent. Don't remove intent.


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?).

 

[Eric Sosman]

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.

 

[Lew]

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.

Plenty of other classes allow overrides, but really many of them arguably
shouldn't.

Read the item in /Effective Java/ "Design and document for inheritance or else
prohibit it" for a better explanation than I can likely offer.

 

[Arved Sandstrom]

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?).

In a way that's what the use of final is - it's a matter of policy. In
the case of this specific Java package the designers very likely had a
better understanding of what use cases they were eliminating by using
final methods (it's a safe assumption considering who the designers
were/are), compared to your average Java programmer, but since the final
keyword requires a deliberate action to put in I'll consider it as a
matter of policy when anyone uses it.

"Policy" is not a non-technical decision. For example, I could say that
it's a matter of policy for me not to provide public accessors for a
class until I've decided that other classes may need to get or set
instance variables on it.

So a programming team could definitely have a policy that certain things
will be marked final, by default, until someone has advanced an argument
that they should not be.

AHS

 

[John B. Matthews]

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.

Plenty of other classes allow overrides, but really many of them
arguably shouldn't.

Read the item in /Effective Java/ "Design and document for
inheritance or else prohibit it" for a better explanation than I can
likely offer.[/QUOTE]

Given that a class should "document its self-use of overridable
methods," can the reader infer that marking certain methods final might
either preclude the need to expose some implementation detail or permit
some alternative implementation?

In particular, I see that a common implementation [1] instantiates a
Sun package named Unsafe. That, in turn, allows (apparently) identical
implementations for compareAndSet() and weakCompareAndSet(), the latter
of which "May fail spuriously," while the former does not. The method
compareAndSet() is used internally.

[1]<http://www.docjar.com/html/api/java/util/concurrent/atomic/AtomicInteger.java.html>