Community
Participate
Working Groups
We should add a semantic coloring for effectively final local variables. That would help avoid 'final-measles' (bug 130888 comment 2). The "Effectively final local variables" coloring should be stronger than "Local variable declarations" and "Local variable references" (like Constants is stronger than Fields).
(In reply to Markus Keller from comment #0) > The "Effectively final local variables" coloring should be stronger than > "Local variable declarations" and "Local variable references" (like > Constants is stronger than Fields). With "stronger", I mean that if the "Effectively final local variables" coloring and the "Local variable declarations and/or references" coloring are both enabled, then the coloring style of the former should win.
After giving this a bit more thought, I'm not sure any more if that's a good idea. There are other requests in this area which can create conflicts, see bug 124679 comment 2, bug 128666. E.g. it's not clear whether "constant", "final", or "effectively final" is _the_ interesting sub-topic for local variables and parameters. All three can be interesting to know, depending on the circumstances. If we implement this, then we need to consider the other options as well and make a well-founded decision.
Created attachment 241733 [details] quick hack Here's a quick hack to try it out. Not ready for release; see also comment 2.
Should this will be applied to all effectively final local variables (not specific to lambda expressions i.e. non-Java8 code, at abstract method's parameters etc)? Example: 'number' at [1]: class C1 { interface FI { int foo(int number); //[1] } FI fi1= number -> number++; }
(In reply to Noopur Gupta from comment #4) Good point, and another reason for not going forward with this without having a good plan. Maybe the interesting property to highlight is not "effectively final" (since that's the common case), but "non-final" (neither explicitly nor implicitly nor effectively final). That would effectively highlight local variables that are truly variable, i.e. reassigned. This would also be interesting outside of lambdas, and even in pre-1.8 code (but I'm not sure if the "effectively final" concept is available for such code).
If these properties (effectively-final, non-final, declaration, variable, lambda-expression, etc.) were assigned to words and spans of characters like CSS classes then CSS specificity rules would quite naturally make "non-final local variable" more specific than "local variable" and equally specific as "local variable declaration". In the latter case whichever of the two was specified later in the CSS would be the one that would apply to something having "non-final local variable declaration" classes.
*** Bug 545934 has been marked as a duplicate of this bug. ***
