commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sawle <>
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 Tue, 28 Oct 2014 09:02:29 GMT
Whilst with primitives it is call by value with objects it is not, and whilst the final modifier
does not stop a method from changing an internal value, it is acknowledgement that they won't,
read writings by Joshua Bolchdku h m

Sent from my iPhone

> On 28 Oct 2014, at 08:55, Bernd <> wrote:
> Hmm,
> You know that Java has no out variables (as it is call by value) and the
> final identifier does not make an object read only. So in fact having final
> modifiers would misslead you even more.
> Actually I like having final fields and variables (for example it avoids
> unneeded initialisation). On the parameters I feel it makes the signatures
> unreadable long, and given that stylistic warnings about Ssigning
> parameters happen in Eclipse anyway I dont need them. (But I dont mind if
> used).
> Greetings
> Bernd
> Am 28.10.2014 09:17 schrieb "James Sawle" <>:
>> I have no view on the use of final modifiers on variables within methods;
>> however on the parameters I think it is very important so that the code
>> self documents to the caller the behaviour that they should expect.
>> Recently I was bitten by a library that I was using in a multithreaded
>> application that was modifying the values I sent it, even though from the
>> contract there seemed no reason for this. Using the final modifier will
>> give that guarantee, without having to add it to the Javadoc and definitely
>> without having to look at the source, which no one apart from a contributor
>> should ever HAVE to do!
>> Sent from my iPhone
>>> On 28 Oct 2014, at 07:21, Benedikt Ritter <> wrote:
>>> I agree with Oliver. This change is just of cosmetic value and makes it
>>> harder to apply patches (the same applies for the "sort methods in abc
>>> order" changes IMHO).
>>> If we come to the consensus that we want a final key word everywhere, we
>>> should add that to our code analysis tools configuration. For now, I
>> don't
>>> feel like we have consens about that.
>>> Benedikt
>>> 2014-10-28 1:24 GMT+01:00 Ralph Goers <>:
>>>> Gary does have a passion for these kinds of changes.
>>>> I am definitely +0 on them but Gary has taken the initiative to make the
>>>> changes to Log4j and has continually sought to keep them up to date even
>>>> though the rest of us don’t really care. We had this same discussion a
>>>> while ago on that mailing list.  The conclusion I came to is that the
>> final
>>>> keyword has value on class attributes and some value on parameter
>>>> declarations and has value only in special cases inside of methods.
>>>> I do know there are cases where the compiler takes advantage of the
>>>> declaration.  I also know that occasionally I have to remove the final
>>>> keyword because I want to modify the value of a local variable.  I
>> really
>>>> dislike them in unit tests.
>>>> Personally I think the way to go is to come to a consensus on where they
>>>> are required, where they are optional, and where they should not occur.
>>>> Ralph
>>>>>> On Oct 27, 2014, at 1:44 PM, Oliver Heger <
>>>>> wrote:
>>>>>> 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
>>>> is
>>>>>>>> implemented. The more entrenched folks are in their positions,
>>>>>>>> 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
>>>>>>>> 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
>> 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
>> 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
>>>>>>> change was done. It is really an invasive commit without any
>>>>>>> announcement. For a collaborative project I do not consider this
>>>> 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
>>>>>> _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
>>>>>>> there was a convention of adding prefixes to variable names derived
>>>> from
>>>>>>> their data type: String sName, int iCount, Double[] adNumbers,
>>>> What
>>>>>>> could argue that this makes code more understandable because
>>>>>>> variable carries meta-information with it. If I suddenly started
>>>>>>> rework the code of multiple components based on this convention,
>>>> 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
>>>> changed.
>>>>>> It is that, and more. Just as important and perhaps more so: When
>> read
>>>>>> code or I am stepping in a debugger and I see a 'final' I know that
>>>> value
>>>>>> is not going to change from under my feet. I can put that aside as
>>>>>> variable (pun intended) in my mind and worry about other aspects
>> 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.
>>>>> Oliver
>>>>>> Gary
>>>>>>> I doubt that you manually inspected the whole code base. Rather,
>>>>>>> assume you used a tool - Eclipse has a corresponding option -
>>>>>>> analyzed all possible code paths to determine whether a variable
>> 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
>>>>>>> harder to read because it adds so much noise. There are some
>>>> 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: <mailto:
>>>>> For additional commands, e-mail: <mailto:
>>> --
View raw message