Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 55291 - Find usages only searches project classes, not JDK + libraries
Find usages only searches project classes, not JDK + libraries
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Refactoring
4.x
All All
: P1 with 39 votes (vote)
: 8.1
Assigned To: Ralph Ruijs
issues@java
http://wiki.netbeans.org/FindUsagesDe...
: UI
: 56021 92757 125707 185726 222870 (view as bug list)
Depends on: 252992 252993 252994 252995
Blocks: 197194
  Show dependency treegraph
 
Reported: 2005-02-21 13:17 UTC by _ rkubacki
Modified: 2015-09-01 11:51 UTC (History)
21 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2005-02-21 13:17:46 UTC
dev build from feb 21, jdk 1.5.0u1

I created a new project and opened java.awt.Window
and tried to find usages of processWindowEvent
method but IDE reported 0 usages though it is used
from processEvent in the same class. BTW: find
usages works if the same pattern is contained
within my project sources.
Comment 1 Martin Matula 2005-02-21 13:39:13 UTC
This is as designed. Find usages and refactoring operations do not
work on sources in archive files. It will work when you unzip the JDK
sources and add them to your project as regular editable files.
Comment 2 _ rkubacki 2005-02-25 11:17:46 UTC
I do not agree. There is a significant difference between refactoring
and find usages in this case. I understand this it would be peculiar
to expect that refactoring will modify these files (usages). OTOH find
usages is a tool that should help me to understand program flow but it
reports only partial results here and causes big confusion.
Comment 3 Martin Matula 2005-04-12 11:17:31 UTC
Reopening as an enhancement.
Comment 4 Jesse Glick 2005-04-16 19:40:22 UTC
Really I consider this a defect, since the user expectation is that you will
find all usages - there is no indication that non-project classes will be
excluded, and it is quite a surprise when you are unable to use this basic
feature to understand the way the JDK and libraries work. (At least the Go to
Class dialog offers you the choice - F.U. does not.) There has been repeated
feedback from users on this point.
Comment 5 mikeskells 2005-06-08 09:51:07 UTC
*** Issue 56021 has been marked as a duplicate of this issue. ***
Comment 6 _ rkubacki 2005-09-29 16:31:28 UTC
Open DocumentContent in our editor/libsrc and look for usages of createPosition
(from class AbstractDocument.Content). No usage is reported but
javax.swing.text.AbstractDocument.createPosition calls this. Please reconsider
your opinion. This is not an enhancement for many people.
Comment 7 Petr Jiricka 2005-09-30 08:02:59 UTC
I agree with Radim and Jesse that this is really painful and should be
addressed. I would also call it a bug. 

Martin, do you oppose to this change because you don't agree with the requested
behavior, or because of implementation difficulties?
Comment 8 Martin Matula 2005-09-30 09:09:24 UTC
IMO in most cases users do not want to get usages in libraries and JDK
(similarly to debugging - JDK sources are disabled by default). So, this needs a
new UI - a check-box to say whether you want to search in non-project files or not.
The biggest problem is performance - currently we use class files for JDK and
libraries, to fix this, we would need to use source files which would slow
things down. I suggest to defer the fix of this issue to the new version of the
lang. infrastructure, which should solve this nicely.
Comment 9 Jan Pokorsky 2008-10-16 16:55:04 UTC
*** Issue 92757 has been marked as a duplicate of this issue. ***
Comment 10 martin.dilger 2011-02-26 18:07:57 UTC
I do really agree in calling this a bug, 
how shall it be possible to inspect library files, and I spent about half an hour until I came to the idea to look for a bug report on this.
Please fix this.
Comment 11 Jan Becicka 2011-04-06 14:26:33 UTC
*** Bug 125707 has been marked as a duplicate of this bug. ***
Comment 12 Jan Lahoda 2012-07-16 13:34:07 UTC
*** Bug 185726 has been marked as a duplicate of this bug. ***
Comment 13 atr_23 2013-04-25 18:18:29 UTC
I think this is an essential feature for all Java developers. Eclipse supports this.
Comment 14 atr_23 2013-04-25 18:19:49 UTC
*** Bug 222870 has been marked as a duplicate of this bug. ***
Comment 15 neugens 2013-06-04 10:21:58 UTC
Is there any work being done on this bug?

This is actually a pretty important issue to fix.

There are few use cases that come to mind. For example, when using a new module whose sources come via maven, searching for usages of a specific field or method in that library allows you to understand how to use this particular API.

Same goes when trying to find a quick fix, say, in OpenJDK. Currently we need to have a project open all the time with the source code, which is practical.

In my opinion this distinction is rather bogus, and a proper fix would be even very trivial for an experienced NetBeans developer.
Comment 16 Jesse Glick 2013-06-04 11:10:43 UTC
(In reply to comment #15)
> when using a new module
> whose sources come via maven, searching for usages of a specific field or
> method in that library allows you to understand how to use this particular API.

This is my main use case too; I run into this bug on a near-daily basis.
Comment 17 neugens 2013-06-04 11:13:37 UTC
(In reply to comment #15)

> Same goes when trying to find a quick fix, say, in OpenJDK. Currently we need
> to have a project open all the time with the source code, which is practical.

Obviously, I mean *not* practical here.
Comment 18 ebeb 2013-06-04 11:21:56 UTC
(In reply to comment #15)
> Is there any work being done on this bug?
> 
> This is actually a pretty important issue to fix.
> 
> There are few use cases that come to mind. For example, when using a new module
> whose sources come via maven, searching for usages of a specific field or
> method in that library allows you to understand how to use this particular API.
> 
> Same goes when trying to find a quick fix, say, in OpenJDK. Currently we need
> to have a project open all the time with the source code, which is practical.
> 
> In my opinion this distinction is rather bogus, and a proper fix would be even
> very trivial for an experienced NetBeans developer.

Although I can't estimate the nececssary effort to implement this, I agree 100% with all the other things.

We have a multi-projects product that consists of 6-7 java projects/libraries which we are managing using Ivy (similar to maven). We have the sources managed by Ivy and available to NetBeans.

Using a real dependency resolution tool is what you actually want to use in a multi project/platform/developer project but using Netbeans makes it hard.

Right now I have to use Find in Files which is more than inaccurate. I feel like I'm back to old vim/ctags days :(
Comment 19 Jesse Glick 2013-06-04 11:58:09 UTC
Note that #191334 can be used to find usages of types from artifacts present in the local Maven repository. That can be used as a partial workaround for this bug, though you may get hits from unrelated artifacts (or unrelated versions of a dependency artifact), and you can only search on types and not specific members. This is also restricted to searches initiated from a Maven project, so it would not work for Ivy-based projects even if they were using the Maven repository, and certainly would not work for projects using other kinds of JAR dependencies.
Comment 20 Petr Jiricka 2013-06-04 12:06:47 UTC
I am trying this out, and here are my steps to reproduce with a recent NetBeans 7.4 build:

1. Create a new Maven Java application
2. Make sure sources are attached to the JDK in Tools -> Java Platforms
3. Choose Navigate -> Go to Type and type 'java.awt.Window'
4. The dialog finds the Window class from rt.jar - open it.
5. Find the processWindowEvent method and choose Find Usages on it
6. Change scope to "Current Package (java.awt)" and press Find

=> No occurrences will be found

With the steps above, this issue is clearly a defect, because I specifically set the scope to "current package" and the IDE allowed me to do that. So I am changing this issue to DEFECT (and assigning to Ralph as the current owner).

Without step 6 (i.e. if I used the default scope of Open Projects), it would be arguable whether this is a DEFECT or ENHANCEMENT, because one could argue that Open Projects scope represents just the sources of the open projects, not the libraries used by these projects. Actually recently I entered an enhancement request to enhance the scopes to include also dependencies - see issue 230534. IMO this would clear up the situation and make the meaning of scopes less ambiguous.

As for this bug, the minimal "fix" should be to disallow the "Current Package (java.awt)" scope in this situation, but of course the fix that we all really want is to actually report the usage of processWindowEvent in the body of processEvent.

BTW, I just noticed that when I choose the "Current File (Window.java)" scope, the usage is reported correctly. So it looks like the refactoring infrastructure is capable of finding usages in libraries - the problem is related to the understanding and treatment of scopes.
Comment 21 ulfzibis 2013-06-04 12:25:24 UTC
Please also consider to make the fix working for official OpenJDK freeform projects as mentioned in bug 185726, e.g.
.../jdk/make/netbeans/swing/
Comment 22 neugens 2013-06-04 12:27:53 UTC
I voted for https://netbeans.org/bugzilla/show_bug.cgi?id=230534

It seems exactly the right approach to fix the problem highlighted by this bug
report.
Comment 23 Jesse Glick 2013-06-04 12:43:38 UTC
#230534 is a little different since that (currently) suggests a scope only including nonopen project dependencies, whereas this bug discusses binary dependencies with attached sources. That said, I would expect a UI option mentioning “dependencies” to include all dependencies, whether in binary or project form. A dropdown listing

· File
· Package
· Project
· Open Projects
· Open Projects & Dependencies

would be intuitive I think.
Comment 24 Marian Mirilovic 2013-06-10 20:13:43 UTC
>11 votes + 5 duplicates ... P2
Comment 25 Ralph Ruijs 2013-06-11 09:48:04 UTC
(In reply to comment #20)
> I am trying this out, and here are my steps to reproduce with a recent NetBeans
> 7.4 build:
> 1. Create a new Maven Java application
> 2. Make sure sources are attached to the JDK in Tools -> Java Platforms
> 3. Choose Navigate -> Go to Type and type 'java.awt.Window'
> 4. The dialog finds the Window class from rt.jar - open it.
> 5. Find the processWindowEvent method and choose Find Usages on it
> 6. Change scope to "Current Package (java.awt)" and press Find
> => No occurrences will be found
> With the steps above, this issue is clearly a defect, because I specifically
> set the scope to "current package" and the IDE allowed me to do that. So I am
> changing this issue to DEFECT (and assigning to Ralph as the current owner).

Although the problem is related, this enhancement is about having support for find usages in jdk + libraries. I'll create a separate issue for the wrongly enabled "Current package" scope.
Comment 26 neugens 2013-07-18 12:36:41 UTC
Any estimates when this will be fixed?

Thanks,
Mario
Comment 27 skoky76 2013-07-23 13:01:21 UTC
Hi,

I also vote for this - I would not call it "enhancement", but simply basic functionality which is standard in IntelliJ or Eclipse. Simply to navigate through the source code of dependent libraries and possibility to find usage within the dependencies is a basic functionality. Lack of this in Netbeans very badly affects it's usability.

Petr.
Comment 28 neugens 2013-07-23 13:14:53 UTC
(In reply to comment #27)
> Hi,
> 
> I also vote for this - I would not call it "enhancement", but simply basic
> functionality which is standard in IntelliJ or Eclipse. Simply to navigate
> through the source code of dependent libraries and possibility to find usage
> within the dependencies is a basic functionality. Lack of this in Netbeans very
> badly affects it's usability.
> 
> Petr.

I agree, it should be marked as DEFECT in my opinion. 

It would be great to have it either in the next major update or even better before as a module update :)

Cheers,
Mario
Comment 29 ulfzibis 2013-07-23 15:32:58 UTC
This bug is 8 years old and there is much need ...
Please make it DEFECT.
Comment 30 neugens 2013-09-25 22:24:59 UTC
14 votes, p2 priority, 8 years of wait, and no hint this will be fixed in the next release... Anyway I bumped version to 7.4, maybe it gets someone to look at that.
Comment 31 Jesse Glick 2013-10-02 12:49:26 UTC
@neugens please do not move the Version field forward. This field represents the *first* version to which an issue is known to be applicable.
Comment 32 Chiana 2013-10-02 14:11:51 UTC
Looks like this has been set/unset as defect/enhancement atleast 2 times earlier...
IMHO this is not an enhancement but a genuine bug...
Comment 33 timmaher 2013-10-21 12:03:56 UTC
This is actually quite a dangerous bug when lots of home grown libraries are in play... Like mine.

Any search of this type should be hierarchical from the class down to the method(s) depending upon user selection. If I select MyClass then I expect to see returned all direct references to MyClass. If I select MyClass.getValue(String aKey) with some sort of return value then I expect the results to be limited to that selection type. Variable and field references may be a bit trickier but not insoluble.
Comment 34 matthies 2013-11-14 12:35:42 UTC
This should be P1 as per the http://wiki.netbeans.org/BugPriorityGuidelines.
Comment 35 neugens 2014-01-13 18:21:55 UTC
Is there any work at all being made on this bug? 7.4 is out but it's still functionally broken.

22 votes, open since 2005, honestly this is embarassing at best.
Comment 36 areso 2014-01-31 13:36:37 UTC
This bug makes Netbeans useless for me.
I tried it out for 2 months, but because of this bug - and this is the only reason - I'm getting back to Eclipse.
Comment 37 tln 2014-01-31 14:12:20 UTC
Well, I also have voted for this issue long ago, but calling it a bug or labelling it embarassing is a little over the edge, isn't it? Guys, Netbeans is free, despite the thousands of hours of work that must have gone into it. Everyone of us is getting a huge productivity gain for free, so I think we should be grateful, not grousing.

Having said this, I do not understand why the Netbeans team are so hesitant with implementing this functionality. I have never seen an issue with more voters, and on top of that it's practically already implemented, the source code parser obviously exists, it only needs to be extended to work on the JDK classes.

But even if this functionality is missing, in my opinion Netbeans is clearly the best free IDE around, Eclipse can't really compete, so I'm still loyal.
Comment 38 _ rkubacki 2014-01-31 14:28:16 UTC
Mind that the source parser will only be able to parse src.jar in JDK and you will not get all the usage from it. Of course it is possible to parse classfiles to let you know about usages inside some function where source is not accessible. Same applies to libraries (dependencies).

Bug vs. enhancement discussion is useless as long as the team can adjust the rules. It is non-trivial task but it would be nice to finally get it done after 9 years.
Comment 39 atr_23 2014-01-31 14:43:33 UTC
@tln: Usage search in dependencies should primarily work on class files. This should be much faster anyway. And yes, it's not just about the JDK, but about all dependencies that are in the classpath.

I don't know how the feature is implemented in Eclipse, but AFAIK usage search is also faster there. I don't know how NetBeans searches for usage, but an IDE wide cache/database for classes and their dependencies would probably be the best way to implement this.

To me the lack of this feature is the major drawback of NetBeans. Every NetBeans user who wants to understand libraries e.g. just by downloading the sourcecode via Maven is severely limited by the lack of this feature.
Comment 40 kaszaq 2014-04-04 14:38:08 UTC
This is one of the things that are considered as must have in IDE these times, yet NetBeans team goes for stuff that are not used too often. I don't understand this.
Comment 41 gfzabarino 2014-04-09 12:58:11 UTC
Really guys, this should be definitely implemented, I used both Eclipse and IntelliJ and both IDEs support this. Is a pain to go over the whole i.e. Spring documentation when you could easily find out how its annotations work by just using Find Usages on them... What's the status of this anyway? It has been created on 2005??? We are in 2014!!!
Comment 42 ulfzibis 2014-04-09 13:11:40 UTC
(In reply to gfzabarino from comment #41)
> Really guys, this should be definitely implemented, ...

But why you decreased the priority ???
Also I think, the version should be the one, where the issue was first discovered.
Comment 43 gfzabarino 2014-04-09 13:14:16 UTC
(In reply to ulfzibis from comment #42)
> (In reply to gfzabarino from comment #41)
> > Really guys, this should be definitely implemented, ...
> 
> But why you decreased the priority ???
> Also I think, the version should be the one, where the issue was first
> discovered.

Sorry about that, changing to P1 and v4.x. First time using bugzilla.
Comment 44 steventrouble 2014-09-20 16:37:19 UTC
+1 please fix this issue. It makes it impossible to understand third party libraries. Had to switch IDEs because of this.
Comment 45 elennaro 2014-10-14 20:49:18 UTC
Add this feature please!
Comment 46 TFruehbeck 2015-02-07 17:52:04 UTC
This is definitely a must-have, can't consider using NetBeans in modern open source environments. (I really thougt I did something wrong before searching for bugs.)
Comment 47 Quality Engineering 2015-06-30 01:20:45 UTC
Integrated into 'main-silver', will be available in build *201506300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/40ddb619b1be
User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
Log: #55291 - Find usages searches JDK + libraries when using property org.netbeans.modules.java.source.usages.BinaryAnalyser.fullIndex
Comment 48 Ralph Ruijs 2015-08-30 13:27:15 UTC
changeset:   570ad1a5cb26
user:        Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
date:        Sun Aug 30 15:25:57 2015 +0200
summary:     #55291 - Enable by default and provide disclaimer
Comment 49 markiewb 2015-08-31 20:04:59 UTC
(In reply to Ralph Ruijs from comment #48)
> changeset:   570ad1a5cb26
> user:        Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
> date:        Sun Aug 30 15:25:57 2015 +0200
> summary:     #55291 - Enable by default and provide disclaimer

Cool Ralph! Without any cmdline-switch in NB8.1?
Comment 50 Quality Engineering 2015-09-01 01:25:53 UTC
Integrated into 'main-silver', will be available in build *201509010002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/570ad1a5cb26
User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
Log: #55291 - Enable by default and provide disclaimer
Comment 51 Michel Graciano 2015-09-01 11:51:27 UTC
I won't mark it as 'officially' verified, but I tested it briefly and looks pretty awesome. Thanks Ralph!

v. Build 20150901-35e5ab47fab7


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo