This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If my code reads: List list = myClass.getList(); FIX IMPORTS should be smart enough to check the return type of getList() and resolve list's type based upon that. Currently, it prompts me whether I am refering to java.awt.List or java.util.List.
I agree with this issue and have updated the fields in this issue to indicate that it's relevant on multiple platforms and even with the latest versions (at least up to 6.5 final). Additionally, the "Fix Imports" feature should look at the methods/members on the class, if any, to help it determine which is the proper class to import. For example, there are many different classes called "Node" -- XML nodes, Swing tree nodes, NetBeans Platform nodes, and so on. However, if I have typed: Node node = myDataObject.getNodeDelegate(); And myDataObject has already been assigned as a org.openide.loaders.DataObject, then Node can assumed to be an instance of org.openide.nodes.Node.
What would be the best choice when Node is resolved in multiple packages and those classes actually form a class tree? Would it be best to choose the widest or narrowest match?
In the case when no exact match can be made there should be no automatic detection. The IDE should leave it for the user. In the case there is a single match for something then it is obvious. In this case: FileObject fo = null; It is not obvious. If contextually fo is ever set to something such as: http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/FileUtil.html#createData(java.io.File) fo = FileUtil.createData(file); Then the analyzer should be able to make a correct determination of the correct import needed for some other line of code such as: FileObject fo = null; instead of making the user come back and waste cycles. Then if they need to change it they can. In the case of: FileObject fo = FileUtil.createData(file); then the IDE can look to the right hand side for the correct type to import automatically. *This should be done as soon as the parser realizes there is a missing import error and not require any user input when the IDE can figure out the correct import*. There is no room for ambiguity there. Too, to correct import mistakes which are not yet causing errors (compile time), there could be a user action available when right clicking on a type or a variable "Change Import" and it could be a sub-menu. It would only be available for class names where there are others with the same short name. When it is rolled over it can present a scrollable popup menu with all the available class names which can be chosen; these would be fully qualified names for the import statement. That would change the import right then and there. It would not be a hint, but would work to let the user work on imports more quickly straight from the UI, but I guess it could be a hint, but it would only be enabled when the user is on a type or a variable.
Notice I'm talking about the user not even having to run fix imports. Eclipse will fix that line for you as soon as you type it without even using code completion. It ads the import and you keep working.
For the record: in the early days of NB6.0, the IDE was trying to filter out FQNs that are not usable in the given source. The filtering is still in the IDE, but the providers that were actually filtering the FQNs were disabled, as noone had time to make them work reasonably for syntactically broken sources. Also, the UI was not very clear (strikeout and gray was used for improper FQNs - I do not think the IDE should completely hide the proposals despite it thinks they are not feasible). The only filtering provider that is currently enabled is the accessibility filter (to filter out inaccessible classes, this is also the only one that was actually removing proposals from the list). See: http://hg.netbeans.org/main/file/tip/java.editor/src/org/netbeans/modules/java/editor/imports/ComputeImports.java
*** Bug 245087 has been marked as a duplicate of this bug. ***