Community
Participate
Working Groups
Steps to reproduce: 1. Create a class original.A with a public, static method m(). 2. Create a class user.B and add the following import statements: import static original.A.m; import original.A; 3. Use both A and m in the body of class B. 4. Move class A (without using a refactoring) to the package "moved". 5. Organize imports in B. The result is a single import statement import moved.A; and a compile error. Expected two import statements (as before): import static moved.A.m; import moved.A;
If you have void use() { abs(2.0); } Organize Imports cannot insert the static import because it would be too expensive (see bug 94078 comment 2). Bug 283287 offers an alternative solution. Also, using the move refactoring adjusts the import. *** This bug has been marked as a duplicate of bug 94078 ***
I'm not asking to insert an arbitrary static import, but only to correct an existing static import. I can imaging that organize import doesn't work this way currently, but figuring out that I want to import static moved.A.m; if I have declared import static original.A.m; and class A is only available in package "moved" should be doable.
(In reply to comment #2) > I'm not asking to insert an arbitrary static import, but only to correct an > existing static import. I can imaging that organize import doesn't work this > way currently, but figuring out that I want to > > import static moved.A.m; > > if I have declared > > import static original.A.m; > > and class A is only available in package "moved" should be doable. Yes, doable, but not something we will spend time on, given that the refactoring does the job. If you don't want to (or can't) use the refactoring, then you can use text search replace to fix the imports. *** This bug has been marked as a duplicate of bug 94078 ***
So you don't consider this a bug that needs to be fixed. Fair enough - if you say that organize import doesn't do this, its not broken. But wouldn't this be a reasonable improvement to the organize import feature?
(In reply to comment #4) > So you don't consider this a bug that needs to be fixed. Fair enough - if > you say that organize import doesn't do this, its not broken. > > But wouldn't this be a reasonable improvement to the organize import feature? I never argued about that. This bug is a special case of bug 94078, which is an enhancement marked as WONTFIX. While this special case (we know the type name) is easier fixable than the general case, we still would not spend time to fix this. Since we try to be honest, we normally set such bugs to WONTIFIX. Anyway, I've now set it to assigned and P5. Maybe you're lucky and someone thinks, it is important enough to spend resources on it - maybe you? ;-)
(In reply to comment #5) > maybe you? ;-) The chances are definitely higher now than if you had closed this as WONTFIX again ;-) (In reply to comment #0) > 4. Move class A (without using a refactoring) to the package "moved". This happens when I rebase a Git change onto a change that moved the class. But thinking about it, I could move the class back to the old location (using the refactoring and ignoring the "found potential matches" warning) and the move it to the new location again. Thats a reasonable workaround, but I'd still prefer to have this enhancement implemented :-)
