commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...
Date Mon, 27 Oct 2014 20:44:19 GMT

Am 27.10.2014 um 02:04 schrieb Gary Gregory:
> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <>
> wrote:
>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>>>>> wrote:
>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>> Patches go stale no matter what...
>>>>>> Right, this can happen during normal development, but not necessarily
>>>>>> because of a big bang change for which there is no technical reason,
>> but
>>>>>> which is just a matter of personal taste.
>>>>> I call it a technical reason, you call it personal taste, we are not
>> going
>>>>> to agree.
>>>> Obviously not. So how do we proceed?
>>> You work it out until a consensus is reached and then that consensus is
>>> implemented. The more entrenched folks are in their positions, the
>>> longer consensus is going to take. (And no, a VOTE is not the right way
>>> to resolve this.)
>>> My own view is that the addition of the final keywords does have
>>> technical merit. Not enough to make me want to spend the time to fix the
>>> projects I work on, but I wouldn't complain if someone else wanted to
>>> make all the necessary changes. Similarly while I think it would be a
>>> shame to throw away all this good work, I could live with that option if
>>> that was the consensus opinion.
>>> The issue of out-dated patches is a red herring. That is a separate
>>> problem. The community needs to apply / review patches faster.
>>> Mark
>> Okay, so back to discussion.
>> First of all I have to state that I am irritated about the way this
>> change was done. It is really an invasive commit without any prior
>> announcement. For a collaborative project I do not consider this as good
>> style. As some replies to this thread show, there is no consensus about
>> the changes performed.
>> As an example on the same level,
> This is a silly example IMO because you talk about using a Windows C
> _naming_ convention in Java, which has zero effect on compiled code, while
> we are talking about using a Java language feature which does matter to the
> compiler. Apples and Oranges.

Not in the sense that both changes aim at making code more
understandable without having any impact on functionality.

>> I could come to the idea that I prefer
>> variable names with special prefixes. In C programming under Windows
>> there was a convention of adding prefixes to variable names derived from
>> their data type: String sName, int iCount, Double[] adNumbers, etc. What
>> could argue that this makes code more understandable because each
>> variable carries meta-information with it. If I suddenly started to
>> rework the code of multiple components based on this convention, I would
>> surely trigger some reactions.
>> IIUC, the purpose behind this change is to make the intension of the
>> programmer explicit that a specific variable is not going to be changed.
> It is that, and more. Just as important and perhaps more so: When I read
> code or I am stepping in a debugger and I see a 'final' I know that a value
> is not going to change from under my feet. I can put that aside as a
> variable (pun intended) in my mind and worry about other aspects of the
> code.

The vast majority of Java code I encounter does not use final modifiers
in this way (I know, it is your mission to change this). Therefore, when
I see a final I ask myself what is the special purpose here? Is it
referenced by an anonymous class?

The information whether a variable cannot be changed has not been that
important for me; this can easily be spotted from the context: if there
is an assignment, well it is changed. Otherwise, your method is probably
too complex and needs refactoring.


> Gary
>> I doubt that you manually inspected the whole code base. Rather, I
>> assume you used a tool - Eclipse has a corresponding option - which
>> analyzed all possible code paths to determine whether a variable can be
>> final. This does not tell too much about the intentions of the original
>> authors. Further, when using such a tool there is not much intellectual
>> work behind this. Please correct me if I am wrong here.
>> From my perspective the excessive use of final modifiers makes code
>> harder to read because it adds so much noise. There are some places when
>> Java requires the use of final; but those special places which may be of
>> interest are now completely hidden in the overall final fog.
>> Oliver
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message