Bug 192214 - Find Usages on class in released *-sources.jar
Find Usages on class in released *-sources.jar
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Refactoring
7.0
PC Linux
: P3 (vote)
: 7.0
Assigned To: Jan Becicka
issues@java
:
Depends on: 192647
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-20 14:56 UTC by Jesse Glick
Modified: 2010-12-03 06:17 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
Changes to SourceUtils.getDependentRoots and RetoucheUtils (8.82 KB, patch)
2010-11-25 15:28 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-11-20 14:56:11 UTC
Dev build. I open https://sezpoz.dev.java.net/svn/sezpoz/trunk/sezpoz and make a Maven Java app with a dep on it:

    <dependencies>
        <dependency>
            <groupId>net.java.sezpoz</groupId>
            <artifactId>sezpoz</artifactId>
            <version>1.9-SNAPSHOT</version>
        </dependency>
    </dependencies>
    <repositories>
        <repository>
            <id>java.net</id>
            <name>java.net</name>
            <url>http://download.java.net/maven/2/</url>
        </repository>
    </repositories>

I create a class using it:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import net.java.sezpoz.Indexable;
@Indexable
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.SOURCE)
public @interface Stuff {}

Now Ctrl-B on @Indexable opens the project source file as expected, and from there Find Usages jumps back to Stuff as expected.

Now edit the dependency to be on version 1.8. Download "Declared Dependencies" and "Sources". Now Ctrl-B on @Indexable jumps to an entry in sezpoz-1.8-sources.jar as expected. But Find Usages shows entries in the 1.9-SNAPSHOT source project - technically incorrect - and no entry for Stuff - definitely incorrect.

Might be a problem with how the maven module reports ClassPath items for the sources JAR, but I am not quite sure what it is supposed to report. (AFAIK the details of what java.source expects ClassPath to report for non-project inputs are not documented anywhere. Probably not so much of an issue for Ant projects because there is no real structure to Ant libraries anyway, i.e. it could not be made to work properly, whereas for Maven repository JARs we can know everything of interest.)
Comment 1 Jan Becicka 2010-11-22 13:09:10 UTC
Hm. I do probably something wrong, but if I change dependency from 
<version>1.9-SNAPSHOT</version>
to 
<version>1.8-SNAPSHOT</version>

I cannot build the project. Download dependencies/sources/javadoc does nothing. No error, no feedback, nothing.

Anyway refactoring/find usages works on files, which are defined on source class path of open projects. I guess, that maven projects do not provide correct class path.
Comment 2 Jesse Glick 2010-11-23 00:47:15 UTC
(In reply to comment #1)
> if I change dependency from 
> <version>1.9-SNAPSHOT</version>
> to 
> <version>1.8-SNAPSHOT</version>
> I cannot build the project.

To be expected, unless you happen to have built the lib from 1.8-SNAPSHOT sources. Don't do that. I am talking about 1.8 (release) vs. 1.9-SNAPSHOT.
Comment 3 Jan Becicka 2010-11-23 10:11:36 UTC
*-sources.jar is not on any source path. As I mentioned before - FU works only on things on source path.
Comment 4 Jesse Glick 2010-11-23 19:01:12 UTC
(In reply to comment #3)
> FU works only on things on source path.

Then the action must be disabled when invoked on a source file which is not in your source path, or an error dialog must be shown explaining this.

Is there no way to find usages of something on the compile classpath of open projects? If so, this is a serious gap. (Ideally I would want to see usages from other parts of the classpath, but at least seeing usages among open projects would be helpful.)
Comment 5 Jan Becicka 2010-11-24 09:42:07 UTC
To make things clear. FU works with items defined on compile classpath and search is performed on sources defined on source class path.

Back to your report:
> Find Usages shows entries in the 1.9-SNAPSHOT source project - technically incorrect 
Yes. But it is what I would expect to see.
> and no entry for Stuff - definitely incorrect.
It works for me. But maybe it started to work after restart of the IDE. Can you verify that?
Comment 6 Jesse Glick 2010-11-24 16:11:25 UTC
(In reply to comment #5)
>> and no entry for Stuff - definitely incorrect.
>
> It works for me. But maybe it started to work after restart of the IDE. Can you
> verify that?

Just rechecked and FU on "@interface Indexable" from net/java/sezpoz/Indexable.java in ~/.m2/repository/net/java/sezpoz/sezpoz/1.8/sezpoz-1.8-sources.jar (read-only) shows only hits in "SezPoz Library" and none in the demo project, despite a dep on <version>1.8</version> and after an IDE restart. Checked also in a fresh userdir (opening both source projects as CLI args) in case there was some issue with persistently stale parser caches.
Comment 7 Jan Lahoda 2010-11-24 17:26:14 UTC
Regarding the missing "Stuff" entry, this is what I think is the problem:
-the refactoring first determines what should be FUed: class Indexable that is resolvable from classpath in sezpoz-1.8-sources.jar
-then it tries to find the source file for the Indexable class on the compile classpath of the Java file in sezpoz-1.8-sources.jar (filtered through SourceForBinaryQuery). But there is no specific ClassPathProvider for it, so the DefaultCPP returns all binaries. So the first source file that matches Indexable is used, which happens to be in the opened (Maven) project
-the FU then correctly finds usages of the incorrect class

Best solution, IMO, would be if proper classpaths could be returned for the sezpoz-1.8-sources.jar (including source CP). After this, the result should contain the "Stuff" entry (I tested this by doing FU on Indexable reference in Stuff.java).

Another problem is that the result with the above change will likely contain all references to Indexable, even the "technically incorrect" ones. This is because:
a) refactoring.java's RetoucheUtils.getClasspathInfoFor:621 uses of all source paths known to the IDE as relevant for non-project sources
b) SourceUtils.getDependentRoots cannot currently find roots depending on binary roots (after mapping sezpoz-1.8-sources.jar to sezpoz-1.8.jar)

I can try to eliminate these restrictions tomorrow, unless there are objects.
Comment 8 Jesse Glick 2010-11-24 17:46:42 UTC
(In reply to comment #7)
> Best solution, IMO, would be if proper classpaths could be returned for the
> sezpoz-1.8-sources.jar (including source CP). After this, the result should
> contain the "Stuff" entry

OK, if it would suffice for the maven module to do this then I will try it. So for release deps there would be:

demoprj/src/main/java (pom.xml dep on ...:sezpoz:1.8)
  COMPILE -> sezpoz-1.8.jar etc.
sezpoz-1.8.jar (in local repo)
  SFBQ -> sezpoz-1.8-sources.jar
  JFBQ -> sezpoz-1.8-javadoc.jar
  BOOT -> default JDK? (*)
  SOURCE -> ????
  COMPILE -> (any binary deps in repo)
  EXECUTE -> COMPILE + sezpoz-1.8.jar?
sezpoz-1.8-sources.jar (in local repo)
  SourceLevelQuery -> 1.5 (from sezpoz-1.8.pom in local repo)
  FileEncodingQuery -> UTF-8 (from POM)
  BOOT -> default JDK? (*)
  SOURCE -> sezpoz-1.8-sources.jar
  COMPILE -> (same as for sezpoz-1.8.jar)
  EXECUTE -> (same as for sezpoz-1.8.jar)

Anything to add/change? Should any of the classpaths from the repo JARs be in GlobalPathRegistry - I guess not? Is there a good place to document what the Java infrastructure expects for all of this?

(*) Could check for animal-sniffer-maven-plugin in POM to see what Java platform level is expected, but this will only work in case you use the default config with no annotations, i.e. all code must link against specified JRE without exception. Some projects let parts of the code use newer JRE features but control these parts with runtime checks, so the IDE would have to parse against the newer JRE. There is also a "toolchain" system in Maven which I can look into, but I don't think it is widely used yet. Anyway for uneditable source JARs it is probably enough to parse against default JRE; the source level can be determined accurately I think.

> Another problem is that the result with the above change will likely contain
> all references to Indexable, even the "technically incorrect" ones. This is
> because

I probably don't understand this part well enough to comment on it.
Comment 9 Jan Lahoda 2010-11-25 15:27:46 UTC
Re ClassPath for sezpoz*.jar:
-for sezpoz-1.8.jar, no ClassPath is needed AFAIK, but SFBQ and JFBQ should return valid results (sezpoz-1.8-sources.jar and sezpoz-1.8-javadoc.jar, respectivelly). This works OK even now, right?
-for sezpoz-1.8-sources.jar, the proposed CPs seem good, except CP.COMPILE, which I would extend with sezpoz-1.8.jar: the sources are not scanned, so no classfiles exist for them and so the built jar on CP.COMPILE should hopefully ensure that the classfiles from the sezpoz-1.8.jar will be used instead of parsing everything from sources.
-no registration to GPR needed, AFAIK (would be actually harmfull, I think)

Re the second part: with the above changes, the FU on Indexable from sezpoz-1.8-sources.jar will also return usages of Indexable from the sezpoz project, which is not correct. I am attaching patch that:
-changes SourceUtils.getDependentRoots to accept also source root corresponding to library sources (accepts only project sources in the current trunk)
-changes RetoucheUtils in refactoring.java to:
--use SourceUtils.getDR on all source roots that have source CP, not only on project sources
--not to use Project.getSources().getSourceGroups(), but rather use the roots from the source CP (not strictly necessary to fix this bug, I guess, but I think this is more correct than use getSourceGroups())

Honza, maybe we can discuss the changes to RetoucheUtils next week?

Thanks.
Comment 10 Jan Lahoda 2010-11-25 15:28:40 UTC
Created attachment 103331 [details]
Changes to SourceUtils.getDependentRoots and RetoucheUtils
Comment 11 Jan Becicka 2010-11-25 16:00:29 UTC
thanks, Honzo. We can discuss it next week
Comment 12 Jan Lahoda 2010-12-02 18:25:33 UTC
I have integrated the java/refactoring part:
http://hg.netbeans.org/main-silver?cmd=changeset;node=8035024becd1

Should hopefully work OK after #192647 is resolved. Please reopen if it does not. Thanks.
Comment 13 Quality Engineering 2010-12-03 06:17:52 UTC
Integrated into 'main-golden', will be available in build *201012030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8035024becd1
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #192214: SourceUtils.getDependentRoots should work also for roots from libraries, adjusting refactoring.java's RetoucheUtils to take advantage of this feature.


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