Bugzilla – Full Text Bug Listing
| Summary: | [select] unqualified URL in javadoc tag is wrongly searched for in other classes and packages. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Lukas Eder <lukas.eder> | ||||
| Component: | Core | Assignee: | JDT Core Triaged <jdt-core-triaged> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Ayushman Jain <amj87.iitr> | ||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | amj87.iitr, lukas.eder | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Created attachment 211438 [details]
A sample Eclipe project to reproduce the issue
(In reply to comment #0) > I like Eclipse's auto-cleanup features when saving files. I recently > discovered, that imports are relevant for Javadoc {@link} tags, which is very > convenient. I think you're misinterpreting the use of the shortened syntax of the @link or @see tag. The shortened, unqualified form is only used to refer to members of the current class. Please see http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#package.class for a detailed explanation Quoting from there: "The first set of forms (with no class or package) will cause the Javadoc tool to search only through the current class's hierarchy. It will find a member of the current class or interface, one of its superclasses or superinterfaces, or one of its enclosing classes or interfaces (search steps 1-3). It will not search the rest of the current package or other packages (search steps 4-5)." I intend to close this is INVALID since this is the expected behavior. (In reply to comment #2) The gist of the above comment is that the import is indeed useless and thus, correctly removed. Thanks for your feedback. This seems to be ambiguously specified, but I'm not sure if you're right. Check out another section of the documentation here: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#seesearchorder The relevant part is this section: > When the Javadoc tool encounters a @see tag in a .java file that > is not fully qualified, it searches for the specified name in the > same order as the Java compiler would (except the Javadoc tool > will not detect certain namespace ambiguities, since it assumes > the source code is free of these errors). This search order is > formally defined in Chapter 6, "Names" of the Java Language > Specification, Second Edition. The Javadoc tool searches for that > name through all related and imported classes and packages. In > particular, it searches in this order: > the current class or interface > any enclosing classes and interfaces, searching closest first > any superclasses and superinterfaces, searching closest first > the current package > any imported packages, classes and interfaces, searching in > the order of the import statement Since this does work also for unqualified members inherited from superclasses, I'm inclined to say that static imports are no different. You can verify that the Eclipse tooling already considers static imported members when hitting F3 on such a Javadoc link, both in the source code editor, as well as in the Javadoc view. Hmm, reading through it again, you're right. "The first set of forms" relates to unqualified members. Interesting... So I was indeed mislead by the fact that hitting F3 will follow the static import. So maybe that's the bug? :-) (In reply to comment #5) > So I was indeed mislead by the fact that hitting F3 will follow the static > import. So maybe that's the bug? :-) I'd say that the facility to navigate to ENUM here does offer some convenience, although it does not agree with the the javadoc semantics (which it doesn't have to). ;) The bug here is that (1) the static import should be flagged as unused and (2)the #ENUM should not be interpreted as MyEnum#ENUM but as MyClass#ENUM which doesn't exist, and so F3 should not work here. I agree with you. Thanks, Ayushman This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build Identifier: Build Identifier: Version: Indigo Release Build id: 20110615-0604 I like Eclipse's auto-cleanup features when saving files. I recently discovered, that imports are relevant for Javadoc {@link} tags, which is very convenient. Unfortunately, it seems that Javadoc {@link} tags referencing items imported using "import static" are ignored when organizing imports Reproducible: Always Steps to Reproduce: 1. Use the sample Eclipse project I attached 2. Go to "pkg1.MyClass" class 3. Modify the class and save. This will trigger an Organize Import action (as configured in the project's settings) alternative reproduction steps: 1. Use the sample Eclipse project I attached 2. Go to "pkg1.MyClass" class 3. Hit Ctrl-Shift-O for organizing imports The workaround is to fully qualify the statically imported field name. In the example project, this would mean to write {@link MyEnum#ENUM} instead of {@link #ENUM}