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
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
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
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
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.
The last sentence is a bit of theory. I don't see that to be true for me at
least.
Following some of
On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt tcu...@vafer.org wrote:
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.
The last sentence is a
2014-10-28 13:18 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt tcu...@vafer.org wrote:
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
On 10/28/14 8:46 AM, Benedikt Ritter wrote:
2014-10-28 13:18 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt tcu...@vafer.org wrote:
You know that Java has no out variables (as it is call by value) and
the
final identifier does not make an
Am 27.10.2014 um 02:04 schrieb Gary Gregory:
On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger oliver.he...@oliver-heger.de
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
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
Does a custom annotation at a class level say
@AccessLevel(default=PRIVATE/PROTECTED, final=true/false) that applies to
all the variables declared help reduce the clutter. With this; only few
variables may really require the non-final characteristics. May be a
@NonFinal annotation can help their
On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger oliver.he...@oliver-heger.de
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
Even I must admit that the use of final here is more of a formality than
a necessity. I believe that's why it's been called a stylistic commit.
The compiler isn't driving you to use it for what you need to accomplish,
and there is no pressing technical need to use it aside from it enforces
13 matches
Mail list logo
