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 to convey intention very clear and as well clutter free.
As always; its just annotation and a one line change to make default level to private or protected and final as true/false so changes are at one place. of course this is already available in lombok libraries and am not sure if we can consume that within apache or perhaps should we write one based on standard annotation libraries. Basically the idea is to keep the code minimal and have annotation declared at one place do the desired intent. Please let know opinion. Murthy On Tue, Oct 28, 2014 at 5:54 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 <oliver.he...@oliver-heger.de> > wrote: > > > > > > > > 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 3:23 PM, Oliver Heger < > >>> oliver.he...@oliver-heger.de> > >>>>>> 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. > > > > Oliver > > > >> > >> 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: dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <mailto: > dev-unsubscr...@commons.apache.org> > > For additional commands, e-mail: dev-h...@commons.apache.org <mailto: > dev-h...@commons.apache.org> >
