Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. Write the following classes: package b; public class B { public static class D { public final static int C1 = 1; } /** * {@link D#C1}. */ public void b() { } } package c; import b.B; public class C extends B { /** * {@link D#C1}. */ public void c() { @SuppressWarnings("unused") int d = D.C1; } } A warning is given in the Javadoc of C.c(), while it shouldn't. The same warning is given if D is an enum (in this case c() body should be: D d = D.C1 - in order to avoid a compilation error). One workaround is to write /** * {@link b.B.D#C1}. */ as the Javadoc of c(). Another workaround is to add import b.B.D; to class C, but this generates an "unused import" in C. More information: This bug is similar to bug #176027, but here D should be visible to C simply because C extends B and we shouldn't need to add b.B.D as an import.
(In reply to comment #0) The current behavior sounds correct to me as: 1 - we do not have a valid import to reference D or 2 - D is not fully qualified (B.D#C1) in such situation, corresponding "Javadoc: Invalid member type qualification" warning message is raised. Also note that the Javadoc tool raises the same warning: warning - Tag @link: reference not found: D#C1
changing resolution
changing resolution to INVALID
re-open to re-assign
changing resolution as INVALID
I do not agree. Apart from the fact that the Javadoc tool is coherent with the current Eclipse behaviour (and it might be a Javadoc tool bug...), consider that: - if D#C1 is not reachable in the Javadoc of c(), why should D.C1 be visible, instead, in c() source code, without the needing of adding any import? No compilation error is given in c() body... - if you try to code-complete D#C1 while writing the Javadoc of c(), Eclipse correctly gives you D#C1, without adding any import: it does not complete with b.B.D#C1, nor adds b.B.D import declaration - if the import declaration would be necessary, as you said, why does Eclipse say that "import b.B.D" is an unused import if you add it by hand to avoid the Javadoc warning? Mauro.
Sorry, I didn't want to reopen the bug without your agreement, it was my mistake.
Please consider that the Javadoc tool might give the warning because of this similar (in some way) bug: http://bugs.sun.com/view_bug.do?bug_id=4848177
The referenced bug seems to be different from this bug: - in the Javadoc tool bug, the problem is some kind of inherited doc not found - in this bug, we fail to find the reference to a field in some inner class If you add an import, correct, you'll get an unused import warning, as referenced in bug 198518, in which you'll also find an explanation as to why no import is needed in B#c() method (int d = D.C1;). And if you look at comment#8 in bug 198518, you'll find of the explanations as to why we try to remain as close as possible with the Javadoc tool. This said, I'll keep this one opened as, while investigating it, we found that /** * {@link B.D#C1} */ produces no error, whereas the Javadoc tool still complains: warning - Tag @link: reference not found: B.D#C1
Having a second look at this bug, I feel like there is no bug and we behave as expected. See bug 233187, bug 222188 and bug 221539 for similar issues about references to inner classes in javadoc. The spec is not very clear about it, but if you look at: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#@see you'll find that you can direct reference an inner class when in the same package. When in a different package (as it is the case here), then the reference must be fully qualified:{@link b.B.D#C1} This is confirmed by the fact that the javadoc tool also raises a warning for the unresolved reference. Will you agree to close this bug as WORKSFORME?
(In reply to comment #10) > Will you agree to close this bug as WORKSFORME? Yes and no... Given that the Javadoc specs are not very clear and in contrast with the general visibility rules of Java code, and given that JDT wants to be as much adherent to them as possibile (even in these controversial cases), I would then expect that code-completing Javadoc for C.c() would then give me {@link b.B.D#C1}, rather than {@link D#C1}. Mauro.
In any case, if you prefer me to open a new bug about the code-completion issue, I think INVALID should be more correct than WORKSFORME for this bug report. Mauro.
closing as INVALID - thanks
(In reply to comment #13) > closing as INVALID - thanks Hi Eric, I filed bug #234776 for the code completion issue.
Verified for 3.4RC4
(In reply to David Audel from comment #15) > Verified for 3.4RC4 (In reply to Mauro Molinari from comment #11) > (In reply to comment #10) > > Will you agree to close this bug as WORKSFORME? > > Yes and no... > Given that the Javadoc specs are not very clear and in contrast with the > general visibility rules of Java code, and given that JDT wants to be as > much adherent to them as possibile (even in these controversial cases), I > would then expect that code-completing Javadoc for C.c() would then give me > {@link b.B.D#C1}, rather than {@link D#C1}. > > Mauro. Sorry for reopening an old bug, but if you see here: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link Typical forms for @see package.class#member You can see that @see Class.NestedClass is considered valid and so Eclipse shoudl allow B.D or B.D#C1.
Modifying the class C from comment 0 like this shows 2 errors: package c; import b.B; public class C { /** * @see B.D#C1 * @see B.D */ public void c() {} } Please open a new bug as this appears to be a different error than the one described in this bug.
Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=426858
