Does pervasive use of final make sense?

T

Timo Nentwig

Hi!

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

Timo
 
M

Michael Rauscher

Hi Timo,

Timo said:
Hi!

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

Depends on how you define "whenever possible" ;-)

Bye
Michael
 
B

Ben Wilson

Timo Nentwig said:
Hi!

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

Timo

For variables whose values do not have to change, declaring them final can
result in certain performance benefits, so here I'd say yes as a general
rule.

For methods and classes, this largely depends on how you fare on the
"generous"/"paranoid" scale. If you have a critical method in your class and
you are afraid of what might happen if someone overrides it, sure go ahead
and make it final. On a number of points, your question is closely related
to the hypothetical question of whether it makes sense to use "private"
whenever possible.

java.lang is full of final, BTW.
 
I

iamfractal

Michael Rauscher said:
Hi Timo,



Depends on how you define "whenever possible" ;-)

Bye
Michael

I'd have thought that you need a very good reason NOT to use final.

Unless you consciously design a method to be overridable, make it final.

(Not that designing methods unconsciously is easy ...)

..ed

www.EdmundKirwan.com
 
X

xarax

Timo Nentwig said:
Hi!

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

Let's see:

1. final class.
2. final field.
3. final instance method.
4. final local variable.
5. final method parameter.


1: final class: This is rare. Usually required when
there is some kind of security spoofing possible for
a non-final class. Example: java.lang.String is final
so that a subclass of String can never exist and thus
never spoof or spy on passwords and such. Some classes
have no meaningful inheritance notion, like utility
classes that only have static methods. See "final
instance method" below for more details.

2: final field: Must be assigned by an initializer
expression, an initializer block, or (for an instance
field) by a constructor. Quite common to see final
fields, especially protected or private implementation
dependent fields that contain work objects, like lists.

Note: A field can be shadowed by a method local variable.
If the programmer intends to use a local variable by the
same name as a final field, but forgets to declare the
local variable, the compiler will catch any assignment
to the field in the method. In general, don't use local
variables that shadow fields, unless you really know
what you're doing. Same goes for method parameters.

3: final instance method: This is an alternative to
a final class, where particular instance methods can
be "locked in" to an implementation, but still allow
inheritance of the overall class. Before attaching
"final" to the class, determine whether it would be
more flexible to use "final" on a subset of the instance
methods.

4: final local variable: Good for readability to show
that a variable contains an invariant value. Also good
to prove the programmer's intent to assign only once
to the variable. Instantiating an anonymous inner class
that refers to the local variable (or method parameter)
requires the local variable to be declared final and to
be definitely assigned by the time that class is
instantiated.

5: final method parameter: I generally make all method
parameters final, since they are copy-by-value. Assigning
a new value to a parameter doesn't change anything in
the caller's context. If, for some reason, the algorithm
is better (or more simply) expressed by "massaging" the
value of a parameter, then I would declare a local variable
of the same type and assign the parameter to that local
variable, then use the local variable in the algorithm. This
also helps during debugging to know what was the original
value passed to the method.

Two cents worth. Your mileage may vary.


--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!
 
J

Jean Lutrin

Timo Nentwig said:
Hi!

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

Timo

Hi,

I see one case where people do indeed often not use final and
I never understood why : in method parameters.

I asked some java guru at work why most people, including himself,
would simply not declare method parameters final and the answer
was actually very vague.

I definetely find it very bad style to modify inside a method
a method parameter (it makes codes more difficult to read, imho).

Most people who don't declare their method parameters final
also don't modify them in the method... And would consider it
bad style to directly modify a method parameter (which is
strange : if the parameter is not to be modified, why not
ensure this property by making it final ?)

Now I'm sure lots of people will people will come with vague
explanations because, well... That's the way they do it ;)

Having said that, adding lots of "final" keywords in a method
declaration makes lloonngg lines of code which then may need
wrapping altough they don't when final isn't added.

Any explanations on this subject are very welcome.

See you all on cljp very soon,

Jean
 
R

Ryan Stewart

Jean Lutrin said:
Timo Nentwig <[email protected]> wrote in message

Hi,

I see one case where people do indeed often not use final and
I never understood why : in method parameters.

I asked some java guru at work why most people, including himself,
would simply not declare method parameters final and the answer
was actually very vague.

I definetely find it very bad style to modify inside a method
a method parameter (it makes codes more difficult to read, imho).

Most people who don't declare their method parameters final
also don't modify them in the method... And would consider it
bad style to directly modify a method parameter (which is
strange : if the parameter is not to be modified, why not
ensure this property by making it final ?)

Now I'm sure lots of people will people will come with vague
explanations because, well... That's the way they do it ;)

Having said that, adding lots of "final" keywords in a method
declaration makes lloonngg lines of code which then may need
wrapping altough they don't when final isn't added.

Any explanations on this subject are very welcome.

See you all on cljp very soon,

Jean

The primary reason that I would hesitate to use final on a method parameter
is that it is misleading and would often do nothing. All parameters in Java
are pass by value. If you pass a primitive, the value of the primitive is
passed. Changing the value of that primitive within the method has no effect
on the original variable passed in. Using final in this case could save you
from thinking that you're changing something within the method when you
aren't. However, when passing objects, a reference to the object is passed
into the method. Making this reference final will keep you from assigning a
new object to this reference. It will *not*, however prevent you from
modifying the object itself. The purpose of passing an object reference to a
method is to use the object, not to assign a new object to it. Therefore,
using final on an object reference method parameter is, at best, useless.
 
M

Michael Rauscher

Hi Timo,

I'd have thought that you need a very good reason NOT to use final.

Unless you consciously design a method to be overridable, make it final.

Even with regard to methods, one needs a very good reason to use final.
One should mind, that final is ultimate.

Bye
Michael
 
V

Virgil Green

Ryan Stewart said:
The primary reason that I would hesitate to use final on a method parameter
is that it is misleading and would often do nothing. All parameters in Java
are pass by value. If you pass a primitive, the value of the primitive is
passed. Changing the value of that primitive within the method has no effect
on the original variable passed in. Using final in this case could save you
from thinking that you're changing something within the method when you
aren't. However, when passing objects, a reference to the object is passed
into the method. Making this reference final will keep you from assigning a
new object to this reference. It will *not*, however prevent you from
modifying the object itself. The purpose of passing an object reference to a
method is to use the object, not to assign a new object to it. Therefore,
using final on an object reference method parameter is, at best, useless.

Actually, I find it useful precisely because it eliminates this error:

class ShowFinal {
private String s;

public void theMethod(String s)
{
s = s;
}
}

Many compilers would flag that s assignment as having no effect, but it's
only a warning. Adding final to the parameter makes the assignment to s a
hard error.

Also, if assignment to the method parameter is prevented, then a later
programmer can be assured, without having to examine all the code, that the
value currently in the local variable s is the same value that was passed
when the method was called. Granted it is only *the same* primitive or
object and the members of some objects can be modified, but at least you can
be assured it is the same object even if it can't be assured (in the case of
a mutable object) that it has the original member values.

- Virgil
 
R

Roedy Green

Most people use final very rarely (so does Sun). Does it make sense to
use final whenever possible?

I like final. It is a reassurance that there is no code hidden
anywhere in the class that could change it. Everything of that form
is a great help when it comes to do maintenance.

someone might even invent a tool that puts finals on everything that
is not changed more than once.
 
R

Roedy Green

I see one case where people do indeed often not use final and
I never understood why : in method parameters.

In an not too bring compiler, putting final on a method helps
inlining. The compiler knows no new method will come along to
override it.

Most of the time you get the same effect with private which is implied
final.
 
R

Roedy Green

I like final. It is a reassurance that there is no code hidden
anywhere in the class that could change it. Everything of that form
is a great help when it comes to do maintenance.

someone might even invent a tool that puts finals on everything that
is not changed more than once.

I am talking about final on variables here. Final classes and final
methods are a different story.
 
F

Filip Larsen

Jean Lutrin wrote
Having said that, adding lots of "final" keywords in a method
declaration makes lloonngg lines of code which then may need
wrapping altough they don't when final isn't added.

I think this is the reason I myself haven't used final much. However, as
with most things, it is a matter of getting used to it. I have tried for
a period of time to start using final where it makes sense (i.e. to
signify that the variable is not going to change), and I must admit that
am I begining to like the looks of it. Lines with final in front of them
more clearly separates the final and non-final stuff in a block and that
makes for better reading later on. Also when doing refactoring that
includes a final variables it is much easier to move around since you
know they only gets assigned this once. Some day I may even get used to
use final on the method parameters.

Any explanations on this subject are very welcome.

The only situation at the momement where I use final on method
parameters are when they are directly used in an inner anonymous class,
or when I for some reason need to stress that one parameter is final
whereas another is not.


Regards,
 
T

Tim Tyler

Roedy Green said:
I like final. It is a reassurance that there is no code hidden
anywhere in the class that could change it. Everything of that form
is a great help when it comes to do maintenance.

someone might even invent a tool that puts finals on everything that
is not changed more than once.

There are many such tools, I believe.

IBM's JAX has been doing this sort of thing for years. For example,
it makes non-overridden methods and classes in your project final.

Assuming you deploy using such tools, you should never use "final" for
performance reasons as a result.
 
T

Tim Tyler

Jean Lutrin said:
I see one case where people do indeed often not use final and
I never understood why : in method parameters.

I asked some java guru at work why most people, including himself,
would simply not declare method parameters final and the answer
was actually very vague.

The main reason for not using final in method parameters is the
effect on readability.

Every single method parameter should be final. It should be
the default - but it isn't :-(

I believe the correct way to deal with the mess is not to
sprinkle "final" everywhere - but to use a lint tool to
issue warnings whenever method parameters are modified.

Checkstyle can do this.

The result is much the same as using final everywhere,
but without all the pointless clutter.

There's currently no convenient modifier for opting out
of the check, though.
 
T

Tony Morris

The primary reason that I would hesitate to use final on a method
parameter
is that it is misleading and would often do nothing. All parameters in Java
are pass by value. If you pass a primitive, the value of the primitive is
passed. Changing the value of that primitive within the method has no effect
on the original variable passed in. Using final in this case could save you
from thinking that you're changing something within the method when you
aren't. However, when passing objects, a reference to the object is passed
into the method. Making this reference final will keep you from assigning a
new object to this reference. It will *not*, however prevent you from
modifying the object itself. The purpose of passing an object reference to a
method is to use the object, not to assign a new object to it. Therefore,
using final on an object reference method parameter is, at best, useless.

Very valid points, however, after some thought you'd soon realise that this
is an argument *for* making method parameters final (as per recommendation
by Joshua Bloch, "Effective Java Programming" which contains more concise
and detailed arguments).

The only time where this general rule doesn't apply (at least, that I can
think of) is in recursive calls, where the parameter is often intentionally
modified.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
 
R

Ryan Stewart

Tony Morris said:
assigning to

Very valid points, however, after some thought you'd soon realise that this
is an argument *for* making method parameters final (as per recommendation
by Joshua Bloch, "Effective Java Programming" which contains more concise
and detailed arguments).

The only time where this general rule doesn't apply (at least, that I can
think of) is in recursive calls, where the parameter is often intentionally
modified.
You'll have to explain yourself more better. I still don't see the point in
making a parameter variable final unless it's to keep you from being sloppy
and trying to assign it a new value within a method, which would be
illogical in most, if not all, cases anyway. I also don't see what you mean
by parameters being modified in recursive calls.
 
R

Roedy Green

You'll have to explain yourself more better. I still don't see the point in
making a parameter variable final unless it's to keep you from being sloppy
and trying to assign it a new value within a method

I don't like the idea of final parameters because the finality of that
variable is PURELY the business of the implementation. Clients have no
concern with it. That information should not be exported to the
outside world.
 
R

Roedy Green

Every single method parameter should be final. It should be
the default - but it isn't :-(

If that happened you would be needlessly blocked from reusing anyone's
code. You would have to go beg them to unlock the methods you needed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top