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.

Bug 192148 - import guess improvement
Summary: import guess improvement
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Editor (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal with 2 votes (vote)
Assignee: Dusan Balek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-18 23:51 UTC by pekarna
Modified: 2013-01-08 20:27 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pekarna 2010-11-18 23:51:01 UTC
Hi, I have a suggestion how to improve guesstimation what to import.

It's simple: Prefer classes from packages which are already used. Example:

   private static final Logger log = LoggerFactory.getLogger(JUnitDiffApp.class);

Now I have slf4j and java.util.logging on classpath.
I start with LoggerFactory - Alt + Enter.
NetBeans offers packages in alphabetical order.
I choose slf4j.
NetBeans adds
   import org.slf4j.LoggerFactory;

Now when I press Alt + Enter the line with Logger, NetBeans could guess that it's 
   import org.slf4j.Logger;
to be imported since org.slf4j is already used.

Small improvement, but that's the kind of things which make NetBeans so smooth to work with.

Thanks for considering.

(PS: I've tried 7.0 nightly and it was pretty stable, and somehow it feels like working more fluently, with background tasks being done without slowing the IDE... Good work!)
Comment 1 pekarna 2011-05-02 00:28:44 UTC
Known type information should also be used. E.g.:

import org.slf4j.LoggerFactory;

static Logger log = LoggerFactory.getLogger( WicketApplication.class );
       ~~~~~~


Now Ctrl+Shift+I suggests  java.util.logging.Logger, even if it's clear that I want to import slf4j's Logger.
Comment 2 pekarna 2011-05-08 01:12:52 UTC
Addition: It's highly improbable that anyone wants to use java.swing.* in a web application. Thus, for WARs, this can be completely omitted.

In general, I'd solve this by

 1) Keeping statistics of the classes used in given project and sorting accordingly
 2) Favoring dependencies over JDK
 3) Perhaps by a project-specific black-list.

BTW this could also affect default "enclose in try block" hint around uncaught exceptions, which currently abruptly imports java.util.logging.
Comment 3 pekarna 2011-05-08 03:33:01 UTC
Ad 3) in #2,
I found that Options > Editor > Code Completion already has a blacklist.
But that's not project specific. I will now blacklist Swing, then remove it when I switch to work on other project? ...
Comment 4 pekarna 2013-01-08 20:27:39 UTC
This seems to be a bit improved in 7.3.beta2.