Community
Participate
Working Groups
Build Eclipse 2.1.2 On the following setup, select package fragment 'p' located in project B and rename it into 'q'. It will rename the 'import p.*;' statement, but did not realize there was still a use for it due to other fragment. It should have inserted an extra import during the rename action. Project A +- package p +- A.java Project B prereqs A +- package p | +- B.java +- package c +- C.java package c; import p.*; public class C { }
Markus, can you have a look? Philippe thinks this might be a 2.1.3 candidate.
Some comments: - fix will not be trivial. Currently rename doesn't do any AST analysis, which is verly likely required to solve the problem. - we should only do some special analysis if two package fragments with the same name exists. This esures that we don't break the 98% case in 2.1.2 - the are some tricky corner cases in the case where two classes with the same name in both package exist Project A +- package p +- A.java Project B +- package p +- A.java depending on the class path renaming one of the p packages might change the semantic of the program (a different class A gets visible). For 2.1.x we should issue an error if this scenario is detected. We should not fix the code.
Couldn't you go for something somewhat simpler ? Perform the package rename, then validate. If an error is detected, then insert the original import back and check again. So you would only do extra work on advanced scenario.
Or what about always inserting a new renamed on demand import, and then enable the 'unused import' diagnosis when doing the validation. It would tell you if the old one is used any longer...
The trick with the "unused import" sounds promising. Here is what our current plan is: - first look if a second package with the same name exists. - then do a reference search for all types in the second package - check if the set of affected CU's is disjoint. If so, no further action is needed. - if CUs exist that import from both package, some "further action is required. This can either be: - inspect the search results and check if all type references are fully qualified. If so, we don't need to do anything. If not, determine if the type is imported via a star import. If so, add another star import. - do some AST analysis. - do the change in memory and let the compiler decide if the import is needed.
Once you know a subsequent fragment exists, you could simply notice that the set of references to the subsequent fragment intersects on one of the reference (can only be the on-demand import). If you have one, then the unused import detection should be enough (or whatever you prefer).
This is what I meant with "if the set of CU's is disjoint". In this case there isn't any CU that imports classes from both package fragments.
Created attachment 7093 [details] Patch for jdt.ui / 2.1.2
Created attachment 7094 [details] Patch for jdt.ui.tests.refactoring / 2.1.2
Fix released to R2_1_maintenance branch.
Created attachment 7123 [details] 2nd Patch for jdt.ui / 2.1.2 An additional fix for situations with multiple projects. Relased to R2_1_maintenance branch.
Also fixed in 3.0 stream.
verified is in M-M20040225-200402251535 (markus)
*** Bug 29600 has been marked as a duplicate of this bug. ***
