Community
Participate
Working Groups
Imports that are used by inner classes, but not referenced by the outer class, are designated by the editor as being unused imports. The check to see if an import is used or not should also include inner classes, which is does not seem to currently do. To recreate: 1) Create a class 2) Create an inner class 3) Make a reference to some object (StringTokenizer, for instance) in the inner class somewhere, and Ctrl-space the name to add the import statement. The import should be underlined in yellow now, and an error should be added to the error tab below.
Routing to JDT/Core.
Are you sure that you don't have another error in your code? For example, this reports two errors: import java.util.StringTokenizer; public class Foo { class B { public static Object bar() { return new StringTokenizer(""); } } } Because a static method has to be in a static inner class or a top level class. The import is reported as unused, because the method is not parsed (its signature is invalid). Do you have something similar? If you remove the static keyword in the bar signature, then the unused import error is removed as well.
My inner class is not static. I have a normal, named inner class...something like: package my.package import java.util.StringTokenizer; public class A { /* ... code ... */ protected class B { public void myMethod() { StringTokenizer strtok = new StringTokenizer("my string"); } } } In this example, like 3, the import statement, would be marked with an '!' warining message and underlined in yellow, with the message telling me that the import for StringTokenizer is not used. If I remove this import, then the warning gets replaced by an error on line 12 because I am using a class without importing it. Its a catch 22, either I get a warning or an error. I can live with the warning, but then that breaks the "Optimize Imports" functionality, because doing so will remove the import, causing the error on line 12. I believe the correct functionality would be to not display ANY error/warning in this code, as nothing is wrong with it as-is.
Cannot reproduce with your test case using 20030827. Can you please double check your steps and reopen this defect then ?
Closing as never reproduced in a long time.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
