Bug 208241 - Select in Projects impl for binary classes in dependencies
Select in Projects impl for binary classes in dependencies
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Project
7.1
All All
: P3 with 1 vote (vote)
: 7.3
Assigned To: Tomas Zezula
issues@java
:
: 208217 (view as bug list)
Depends on: 215297 216047
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-10 11:26 UTC by Petr Jiricka
Modified: 2012-12-13 14:21 UTC (History)
6 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 Petr Jiricka 2012-02-10 11:26:50 UTC
1. Add a library to your java project
2. Navigate to some class file (e.g. LibClass.class) node under the Libraries node and open this class file: a synthetic read-only editor containing disassembled code from the class file will be opened
3. Navigate to some other place in the projects view
4. In the editor popup menu, choose Select in Projects

=> I would expect that LibClass.class will be selected in the projects view, but it's not.
Comment 1 Tomas Zezula 2012-02-10 11:49:59 UTC
Nothing in common with java navigation.
Also I doubt it can work as you described. It does not work even when you have attached sources.
You start with a binary, you translate the binary to source using SFBQ (or generate source file). Now you want to navigate back, the BFSQ translate the source into binary. Now comes the tricky part, the binary is on project cp but in most case it's not owned by project (FOQ), so there is no mapping from cp resource to project. Such a one to one mapping even does not exist, for example rt.jar (classes.jar in your case) is on all project cps, which one should be used? To solve this problem you will need something like ProjectMember or ProjectContext which propagates through IDE features. But for actions which do not start in the project window it's hard or impossible to find some reasonable ProjectContext, so I am not very fond of it.

Probably wantfix.
Comment 2 Jesse Glick 2012-02-14 19:00:26 UTC
No "project context" is needed; a project's LogicalViewProvider.findPath could, if passed a generated source corresponding to a class in the project's classpath, select the appropriate subnode under Libraries. (As to the rt.jar case, SiP will just check each project in turn until it finds one which can locate the class.) I do not think the effort to implement such a feature would be justified in actual usage, though.
Comment 3 Jesse Glick 2012-02-14 19:06:47 UTC
*** Bug 208217 has been marked as a duplicate of this bug. ***
Comment 4 kofeka 2012-02-14 19:17:42 UTC
I insist, this is not not an enhancement, this is obviously a usability bug which (among other usability bugs) prevents from  using Netbeans. We're now back to Eclipse. I'm not sure how these "wontfixes" can help Netbeans.

PS
Architectural mistakes are not a reason for not making the product better whether it's simple or not.
Comment 5 Jesse Glick 2012-02-14 20:05:28 UTC
What is the actual use case (purpose) for selecting a class file under Libraries in this way? Implementing this would require nontrivial work and I have never heard of another request for it, but it can be reopened if you consider this an important part of IDE workflow.
Comment 6 Petr Jiricka 2012-02-15 09:07:46 UTC
My use case was that I was trying to find out which jar file of a multi-jar library contains a particular class (starting from a usage of this class in a Java source), and I must say I am not aware of a simple way to accomplish this, as e.g. Find in Projects only searches in sources. From my point of view, the heuristic to just find the first usage if the jar is used by multiple projects (like rt.jar) would be good enough.

But if you say that implementing this would be a significant amount of work, then I don't insist on this being implemented.
Comment 7 Jesse Glick 2012-02-15 16:46:23 UTC
(In reply to comment #6)
> find out which jar file of a multi-jar library contains a particular class 
> (starting from a usage of this class in a Java source)

Makes sense.

Would probably need one impl in java.api.common (LibrariesNode) and one in maven (DependenciesNode). Bug #7551 would make it architecturally nicer by letting each Node communicate what it could select.
Comment 8 Tomas Zezula 2012-02-16 09:16:56 UTC
In reply to comment # 2:
>No "project context" is needed; a project's LogicalViewProvider.findPath could,
>if passed a generated source corresponding to a class in the project's
>classpath, select the appropriate subnode under Libraries.
Which does not work as it selects the source from random project not from the project user has started with.

Here is an example:

Project_1
  -Libs
     -foo.jar
         -A.class
Project_2
  -Libs
     -foo.jar
         -A.class


User selects A.class form Project_2 and opens source. Now he does select in project view.
Which project's LogicalViewProvider should be used? Check each project is clearly wrong as you will end with Project_1/Libs/foo.jar/A.class but should be Project_2/Libs/foo.jar/A.class.
Comment 9 kofeka 2012-02-16 09:49:07 UTC
In ambiguous cases Eclipse, for instance, does ugly things  opening/showing/debugging classes from random projects. You can do much more better, I guess. Why just not ask the user? In cases when you're not able to decide on your own, give them option to select.

In this case I would expect a dialog where I could select a project (may be randomly, but this will be my choice and no complains to the IDE).

And more, while the case you mention is possible and in big projects is not very rare, from my practice this ambiguity happens less frequently then the case where the IDE is able to select the right project.
Comment 10 Jesse Glick 2012-02-20 19:05:48 UTC
(In reply to comment #8)
> you will end with Project_1/Libs/foo.jar/A.class but should be
> Project_2/Libs/foo.jar/A.class.

So what? Just select Project_1/Libs/foo.jar/A.class anyway. Here I am assuming that both projects are in fact referring to the same JAR (using the same path), so it does not really matter where you browse foo.jar, any more than it would matter which node you double-clicked to open the (associated or decompiled) source file.
Comment 11 Tomas Zezula 2012-02-20 19:21:36 UTC
>Just select Project_1/Libs/foo.jar/A.class anyway. Here I am assuming
>that both projects are in fact referring to the same JAR (using the same path),
Right.
>so it does not really matter where you browse foo.jar
It does. Lots of people are using the "Select in Project" action to navigate to project. When I want to compile project or change project metadata for some file owned by a project I just call "Select in Project" and it shows me the file in the project. I don't need to search the project among 100+ other projects. In fact I don't use "Select in Project" for anything else, I am opening classes by Go To Type.
If the IDE selects me file in some random project I will do an action on wrong project.
Comment 12 Jesse Glick 2012-02-20 22:26:45 UTC
(In reply to comment #11)
> When I want to compile project or change project metadata for some
> file owned by a project I just call "Select in Project" and it shows me the
> file in the project.

And that works fine - for a file actually owned by the project. In this case the JAR is not owned by any individual project, so you could not use that shortcut. Nor can you use it today in these cases; fixing this issue would not change that.
Comment 13 Tomas Zezula 2012-02-21 15:22:24 UTC
>And that works fine - for a file actually owned by the project. In this case
>the JAR is not owned by any individual project, so you could not use that
>shortcut. 
Unfortunately users are not FileOwnerQuery based. If user sees the jar under the project
it expects that the file is owned by the project. There are several other issues related to this like user has 2 projects with 2 different JavaPlatforms on the top of single JDK. In one project the javadoc (sources) are taken from the second JavaPlatform, etc.
>Nor can you use it today in these cases
Currently it does not select anything
>fixing this issue would not change that.
It will select node under a random project. Which is not the same as selecting nothing.
User may do some destructive operation on such a selected project.
Comment 14 Jesse Glick 2012-02-21 19:17:26 UTC
(In reply to comment #13)
> User may do some destructive operation on such a selected project.

Despite seeing the actual project label in the Projects tab, the title of the main window and Properties dialog, etc.? Possible, but I am not convinced this is a good enough reason to reject a sensible enhancement; would not matter for the use case in comment #6, for example.

Comment #9 proposes behaving specially when the choice would be ambiguous, which would mean that (a) no project owns the selection, (b) >1 project returns non-null for it from findPath; or (a) some project owns the selection but does not return it from findPath, (b) >1 other project claims to find it. (See ProjectsRootNode.findNode.) In such a case the IDE could select nothing and print a warning to the status line, or select them all, or produce a list of available projects in a combo box in a dialog and ask the user to pick one to select, etc.
Comment 15 Tomas Zezula 2012-02-22 09:07:54 UTC
>but I am not convinced this is a good enough reason to reject a sensible enhancement
I've already learned that "simple enhancements" do not work. Simple enhancements sometimes introduce more problems than benefits, for example the HTTP javadoc.

The comment 9 is a solution I've thought about. When the path is ambiguous asking user is the only way how to do the selection right. The UI problem may be when user do selection on java.lang.String while having 100+ projects. The dialog will offer 100 projects to choose from.
Also I still think that there are cases like the Peter's original report which can be done in deterministic way. When I click on the java.lang.String under Project_B  and I (the LibrariesNode) do the open (generate) of the java file I have the Project and I can pass it to the editor to make it deterministic.
Comment 16 Tomas Zezula 2012-02-22 09:10:29 UTC
When I will some time I will prototype the Project passing among the LibrariesNode and editor.
Comment 17 Jesse Glick 2012-02-22 22:41:05 UTC
(In reply to comment #15)
> when user do selection on java.lang.String while having 100+ projects. The
> dialog will offer 100 projects to choose from.

So the user will learn that this is a dumb thing to do. The plausible use cases are when just one project has the library, or when it makes no difference which project you select the node under.

> When I click on the java.lang.String under
> Project_B  and I (the LibrariesNode) do the open (generate) of the java file I
> have the Project and I can pass it to the editor to make it deterministic.

This seems like a bad idea to me.
Comment 18 Tomas Zezula 2012-07-13 09:02:07 UTC
Fixed jet-main 5d1b82e5768a
Comment 19 Quality Engineering 2012-07-14 02:56:57 UTC
Integrated into 'main-golden', will be available in build *201207140002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5d1b82e5768a
User: Tomas Zezula <tzezula@netbeans.org>
Log: #208241:Select in Projects impl for binary classes in dependencies
Comment 20 Petr Jiricka 2012-07-25 21:48:59 UTC
This still does not work for me in Maven projects, is it supposed to?
Comment 21 Tomas Zezula 2012-07-27 07:37:48 UTC
No. Maven has its own fork of libraries nodes, forked in some state and them unmaintained.
Comment 22 Milos Kleint 2012-07-27 08:36:16 UTC
(In reply to comment #21)
> No. Maven has its own fork of libraries nodes, forked in some state and them
> unmaintained.

More or less a different codebase given the difference between ant libraries and maven dependencies.

Is this issue supposed to be moved to projects/maven or another one created specifically for maven support?
Comment 23 Tomas Zezula 2012-07-27 08:48:36 UTC
Create a new one.
But I would not waste a time to do it.
The Libraries nodes should be merged back from all the forks to some stable API in java.project similarly as we did with ProjectProblemsProvider.
Comment 24 Petr Jiricka 2012-07-27 09:22:40 UTC
Ok, I still filed a new issue #216047 for Maven.


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