Community
Participate
Working Groups
3.1m6 In unit X.java, had the following source: public class CI { Comparable<?> x; void put(Comparable<?> x) { this.x = x; } Comparable<?> get() { return x; } void test() { CI ci = new CI(); ci.put(new Integer(3)); Integer x = (Integer) ci.get(); } } I wanted to rename CI into X for all occurrences in file. Selected CI in class declaration header Pressed ctrl-1 > rename in file It did not toggle to linked mode, and edits did not affect other references in file.
the problem in this scenario is that the AST does not contain any bindings as the main type does not correspond to the CU name. However, instead of 'rename in file' use the quick fix offered on 'CI': Rename to 'X'. The quick fix correctly renames the file and all references in code. It does does by creating an AST with the name 'CI.java' and so gets bindings again. The only thing I can do here is to ask jdt.core to be more tollerant when CU and type name do not match and return bindings anyways. Philippe, is that a possibility?
Kent - the check is located inside CompilationUnitScope#buildTypeBindings(...) what if removing the "continue" statement after reporting the problem (line 116) ?
I checked that with this one change, the quick assist operates fine. Readopting the problem.
I don't think we should change this. What happens when there is a file CI.java that defines the type CI? CI.java should not be tagged with the duplicate type error since its the only file that can correctly define the type CI.
That isn't much different from a non-public case where a duplicate type would be reported. One thing we could do then, is probably losing the public modifier in this scenario.
Released, as it improves greatly some refactoring scenario.
We now complain against the file CI when it defines the type CI.
Will leave as is. Before the change it was still possible for a secondary type to be accepted & the public type in the correct file to be tagged as a duplicate.
Verified in I20050510-0010
