Community
Participate
Working Groups
The "join variable declaration" quick fix is offered for code like this: String something; something = "blah"; But it is not for initialized variables, like this: String something = null; something = "blah";
Move to JDT/UI
In this case, the quick assist name should tell that the initializer gets removed, e.g. 'Join variable declaration, remove initializer'. The 'Split/join variable declaration' command on the declaration should stay with 'Split' when the quick assist is invoked on the declaration (but the 'Join' quick assist should be offered as well). If anyone is up for a patch: The code is in QuickAssistProcessor.getJoinVariableProposals(..).
(In reply to comment #2) > In this case, the quick assist name should tell that the initializer gets > removed, e.g. 'Join variable declaration, remove initializer'. I agree with this for a non null initializer >String something="initializer"; >something = "blah"; But is the 'remove initializer' message to the user really necessary when the initializer is 'null'? >String something = null; >something = "blah"; You initialize a variable to null to make sure that it is initialized and the compiler no longer complains about it. Also in this case there is no real loss of data. (If the initializer is non null then the user might want to preserve that and hence should be informed before removing it)
(In reply to comment #3) Agreed.
Created attachment 182924 [details] proposed fix for the null initializer case Patch does 2 things - Offer 'Join variable declaration' quick assist when the initializer is null - *Not* offer 'Split variable declaration' quick assist when the initializer is null. It looks odd if you see both join and split assists together, and secondly splitting away null initializer is not useful. e.g. String something; something = null;
Created attachment 182946 [details] fix + tests added tests.
(In reply to comment #5) > - *Not* offer 'Split variable declaration' quick assist when the initializer is > null. > > It looks odd if you see both join and split assists together, and secondly > splitting away null initializer is not useful. e.g. > String something; > something = null; Markus, you are ok with this bit?
(In reply to comment #7) > (In reply to comment #5) > > - *Not* offer 'Split variable declaration' quick assist when the initializer is > > null. > > > > It looks odd if you see both join and split assists together, and secondly > > splitting away null initializer is not useful. e.g. > > String something; > > something = null; > Markus, you are ok with this bit? ping.
> - Offer 'Join variable declaration' quick assist when the initializer is null That's good. > - *Not* offer 'Split variable declaration' quick assist when the initializer is > null. > > It looks odd if you see both join and split assists together, and secondly > splitting away null initializer is not useful. e.g. > String something; > something = null; It's not useful in itself, but 'Split variable declaration' is always just the first step of a larger code change. There are cases where you want to split off a null initializer, e.g. here: private void foo() { String something= null; if (equals(null)) { System.out.println("b'"); } else if (hashCode() == 1) { something= "blah"; System.out.println("a'"); } else { System.out.println("a'"); System.out.println("something"); } System.out.println(something); } If I want to change this code to be sure that 'something' is initialized in all branches, I can split the declaration and move it into the first block (with a simple Alt+Down). Please add the 'Split variable declaration' quick assist back in this case. I know that this will introduce a conflict, since the two quick assist use the same commandID, so their key bindings will be duplicated. But this can easily be solved in the second proposal by checking whether resultingCollections already contains a proposal with that commandID. If you want the 'join' proposal to win the race for the commandID, you can also change the order in QuickAssistProcessor#getAssists(..). OK to release with these changes.
Created attachment 183903 [details] final fix (In reply to comment #9) > It's not useful in itself, but 'Split variable declaration' is always just the > first step of a larger code change. Fair enough. > If you want the 'join' proposal to win the race for the commandID, you can also > change the order in QuickAssistProcessor#getAssists(..). Done this as well.
Fixed in HEAD.
Support is missing for primitives. Filed bug 344569.
Verified in 3.7 M7.
