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.
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.
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.
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.
Reopening as an enhancement.
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.
*** Issue 56021 has been marked as a duplicate of this issue. ***
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.
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?
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.
*** Issue 92757 has been marked as a duplicate of this issue. ***
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.
*** Bug 125707 has been marked as a duplicate of this bug. ***
*** Bug 185726 has been marked as a duplicate of this bug. ***
I think this is an essential feature for all Java developers. Eclipse supports this.
*** Bug 222870 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
(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 :(
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.
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.
Please also consider to make the fix working for official OpenJDK freeform projects as mentioned in bug 185726, e.g. .../jdk/make/netbeans/swing/
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.
#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.
>11 votes + 5 duplicates ... P2
(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.
Any estimates when this will be fixed? Thanks, Mario
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.
(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
This bug is 8 years old and there is much need ... Please make it DEFECT.
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.
@neugens please do not move the Version field forward. This field represents the *first* version to which an issue is known to be applicable.
Looks like this has been set/unset as defect/enhancement atleast 2 times earlier... IMHO this is not an enhancement but a genuine bug...
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.
This should be P1 as per the http://wiki.netbeans.org/BugPriorityGuidelines.
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.
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.
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.
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.
@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.
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.
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!!!
(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.
(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.
+1 please fix this issue. It makes it impossible to understand third party libraries. Had to switch IDEs because of this.
Add this feature please!
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.)
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
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
(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?
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
I won't mark it as 'officially' verified, but I tested it briefly and looks pretty awesome. Thanks Ralph! v. Build 20150901-35e5ab47fab7