Community
Participate
Working Groups
Consider this prototype code: void foo() { final PreparedStatement statement; try { statement = xxx.prepareStatement(...) } catch (..) { // handle errors } return statement; } For this kind of thing I often use a final local variable - mostly to enable the compiler to find my errors (like assigning more than once). However, with Eclipse I get parse errors (cursor on the line that declares the local var) when using refactoring functions, such as "Reorganize imports". The Eclipse version used is Eclipse 2.1 M4.
Test it with the following example under M4 public class A { public int foo() { final int value; try { value= init(); } catch(Exception e) { // handle errors } return value; } public int init() { return 10; } } Activating Organize imports claims that the CU has parse errors. The refactoring actions claim that the variable value may not have been initialized which is the correct behaviour. Martin, can you comment on the organize import case.
Fixed it for 'organize imports'. Only syntax errors should stop the action. > 20030107 Add Philippe as CC: The bug report says other compilers tolerate the code when the variable is set to final, eclipse doesn't. Who's right?
Thanks for caring, guys. To simplify the situation (the rules for definitive assignment really *ARE* complicated with try/catch/finally), here's a more obvious example. Eclipse also complains with: public void foo() { final int bar; bar = 1; } There's no conditionality involved. My impression is that you always get parse errors when a local final variable isn't immediately assigned. However, this is really ok - it's an explicit g. Actually, I found this feature of Java while reading the Java language reference. For reference, take the example in the Java Language Specification, Second Edition (English), page 409, example method "unflow".
There is no parse error at all in the original code sample, only an issue with definite assignment (which doesn't prevent parsing). Suspecting some inconsistency in the DOM AST.
Moving to JDT/Core for further investigation on the DOM AST conversion. It seems fooled by the extra modifier bit: AccBlankFinal (which it shouldn't consider).
AccBlankFinal got introduced recently, and DOM AST didn't get updated accordingly. Fixed in latest.
Regression test added.
*** Bug 31070 has been marked as a duplicate of this bug. ***
Verified.
