Home » Newcomers » Newcomers » cleanup > use 'final' does not work
|
| Re: cleanup > use 'final' does not work [message #167471 is a reply to message #167350] |
Fri, 25 August 2006 16:29   |
Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Ulrich Scholz" <d4@thispla.net> wrote in message
news:6dd216a2c880a372e8e6df38aa4fd09e$1@www.eclipse.org...
> Hi everybody,
>
> It seems as if Source > Clean Up > Use modifier 'final' where possible
> does not do anything.
>
> It always results in "The refactoring does not change any source code"
> even if there are plenty variables and parameters where it could safely be
> added. (Of course, this message is given only if there is nothing else to
> clean up)
>
> Do I misunderstand something here or is this a bug?
It does seem to have only limited effect. For instance, I created a new
project containing the following class:
package x;
public class A {
private Object _x;
A(Object x) {
_x = x;
}
Object getX() {
return _x;
}
}
And when I ran Source -> Clean Up... and selected "Use modifier 'final'
where possible", with all the sub-checkboxes checked, the only thing it
changed was the parameter to A(). It did not set the _x field to final,
which seems like the most obvious and useful action.
So this seems like a bug, or at least a request for enhancement, to me as
well. You could search Bugzilla to see if anyone has already entered one,
and if not, do so yourself.
|
|
|
| Re: cleanup > use 'final' does not work [message #167711 is a reply to message #167471] |
Mon, 28 August 2006 09:13 |
 Ulrich Scholz
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Walter Harley wrote:
> And when I ran Source -> Clean Up... and selected "Use modifier 'final'
> where possible", with all the sub-checkboxes checked, the only thing it
> changed was the parameter to A(). It did not set the _x field to final,
> which seems like the most obvious and useful action.
Thanks Walter,
your comment made me reinvestigate "sub-checkboxes". Now it does what I
expect. In
public class Testtest
{
public class A {
private int _x;
A(int x) {
_x = x;
int xx = x;
System.out.println(xx);
}
int getX() {
return _x;
}
}
}
it makes x and xx final. Making _x final automatically is - I guess -
much harder. For example, it is possible to change private variables via
reflection. This could break existing code, e.g., test cases.
But one thing is sure: The check boxes at Clean Up > Use modifier 'final'
where possible > {Select All, Deselect All, Restore Defaults} are named in
a confusing way.
Yours, Ulrich
|
|
|
| Re: cleanup > use 'final' does not work [message #168551 is a reply to message #167711] |
Thu, 31 August 2006 02:44 |
| Eclipse User |
|
|
|
Originally posted by: eclipse4.rizzoweb.com
Ulrich Scholz wrote:
> Walter Harley wrote:
>
>> And when I ran Source -> Clean Up... and selected "Use modifier
>> 'final' where possible", with all the sub-checkboxes checked, the only
>> thing it changed was the parameter to A(). It did not set the _x
>> field to final, which seems like the most obvious and useful action.
>
> Thanks Walter,
>
> your comment made me reinvestigate "sub-checkboxes". Now it does what I
> expect.
[cut code sample]
> it makes x and xx final. Making _x final automatically is - I guess -
> much harder. For example, it is possible to change private variables
> via reflection. This could break existing code, e.g., test cases.
>
> But one thing is sure: The check boxes at Clean Up > Use modifier
> 'final' where possible > {Select All, Deselect All, Restore Defaults}
> are named in a confusing way.
I'm curious about why some programmers feel it is a valuable thing to
make variables final automatically? The traditional reason I've heard in
the past, performance improvement, is not very valid any more given
modern JVM performance.
I am even more curious as to why this feature was ever included at all.
Given the numerous existing bug reports and feature requests that face
the Eclipse dev team, this seems like one of those silly little things
that some people like to have but in reality is not very useful. IMO,
not a prudent use of Eclipse developer time given all of the other work
that can be done.
Eric
|
|
|
| Re: cleanup > use 'final' does not work [message #168755 is a reply to message #168551] |
Thu, 31 August 2006 18:13 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Eric Rizzo" <eclipse4@rizzoweb.com> wrote in message
news:ed5i55$rkv$1@utils.eclipse.org...
> I'm curious about why some programmers feel it is a valuable thing to make
> variables final automatically? The traditional reason I've heard in the
> past, performance improvement, is not very valid any more given modern JVM
> performance.
My opinion:
The only advantage I know from making function arguments final is that it
can make the code a little easier to comprehend; that is, it reduces the
amount of context one needs to understand any given line. Not a huge
benefit given that good design usually results in short function bodies
anyway.
However, the bigger the object is, the more its readability is enhanced by
making fields final whenever possible. After all, in terms of readability a
field in a large object is not much different than a global variable, and
all the same problems with global variables apply.
Also, there can be a significant advantage to making fields final, in
avoiding certain multithreading bugs. Never use a non-final field as a
lock!
That's why it's a little troubling that the refactoring operation seemingly
works on local variables but not on fields.
|
|
|
| Re: cleanup > use 'final' does not work [message #169169 is a reply to message #168755] |
Mon, 04 September 2006 03:52 |
| Eclipse User |
|
|
|
Originally posted by: eclipse4.rizzoweb.com
Walter Harley wrote:
> "Eric Rizzo" <eclipse4@rizzoweb.com> wrote in message
> news:ed5i55$rkv$1@utils.eclipse.org...
>> I'm curious about why some programmers feel it is a valuable thing to make
>> variables final automatically? The traditional reason I've heard in the
>> past, performance improvement, is not very valid any more given modern JVM
>> performance.
>
> My opinion:
>
> The only advantage I know from making function arguments final is that it
> can make the code a little easier to comprehend; that is, it reduces the
> amount of context one needs to understand any given line. Not a huge
> benefit given that good design usually results in short function bodies
> anyway.
I don't see that adding "final" at variable declarations makes it any
more readable. When perusing code that suffers from even a little bit of
bloat (as opposed to nicely structured into small methods and classes),
to have to remember which fields were declared final and which were not
actually seems to add more comprehension overhead.
In fact, it makes things MORE confusing if you can't assume that a
variable is final for a particular reason. I mean, if everything that
*might* could be declared final actually is, you loose the important
meaning of final, specifically to indicate that it is "a value that is,
by design, not supposed to change." By over-using final, it is diluted
into meaning "a value that does not happen to change with the current
implementation." But may or may not have a contractual or design reason
to be so. See? Diluting the meaning makes it more confusing.
> However, the bigger the object is, the more its readability is enhanced by
> making fields final whenever possible. After all, in terms of readability a
> field in a large object is not much different than a global variable, and
> all the same problems with global variables apply.
I don't see any connection between large objects resembling global
variables (which I agree with, by the way) and using final wherever the
current implementation happens to allow it.
> Also, there can be a significant advantage to making fields final, in
> avoiding certain multithreading bugs. Never use a non-final field as a
> lock!
In that case, a mutex or lock object being final has a particular reason
for being final, not just because it is possible to make it so (what the
refactoring does). I do not object to using final for a mutex lock (or
various other reasons), since it would be by design. When it is a
person's conscious decision, OK. But going through the code and looking
for opportunities to add 'final' wherever possible? That is just plain
silly and will make refactoring the code more difficult, and as I said
dilutes the meaning and importance of "final."
Finally, I can't believe some Eclipse developer spent time on this
feature when there is so much else to do that actually impacts people's
productivity every day. Seems to me like very foolish stewardship of the
limited resources available to work on Eclipse.
Eric
|
|
|
Goto Forum:
Current Time: Tue Apr 23 06:28:48 GMT 2024
Powered by FUDForum. Page generated in 0.08417 seconds |
] 
Search
Help
Register
Login
Home
