Community
Participate
Working Groups
Build ID: I20070209-1006 Steps To Reproduce: 1. Enable Pref / Java / Compiler / Javadoc / Report errors in tags 2. Create package and file: package otherpkg; public class C { public static class Inner { } } 3. Create second package and file to show the problem: package somepkg; import otherpkg.C.Inner; /** * {@link Inner} -- warning "Javadoc: Invalid member type qualification" */ public class MemberTypeDocTest { /** * {@link Inner} -- works */ void m() { } } More information: When you have a member type imported, a {@link} to that type is handled correctly in a method javadoc block. However in a class javadoc block, the same {@link} produces a warning that is difficult to get rid of. I never had that trouble in 3.2, it must be new in 3.3. Note: In the class javadoc, typing "{@link Inn<Ctrl-Space>" completes "Inner" and adds the import statement as seen above -- and also produces the warning. For the user, it's adding to the confusion if Eclipse generates code and then goes on to tag it as a warning.
Eric, please investigate
There are several points here: 1- the " {@link Inner} -- works" Javadoc in a method block sounds correctly handled, whereas it is not taken into account (verified). By default, when you enable the preference Java / Compiler / Javadoc / Report errors in tags, the default visibility is set to Public. With such default settings, errors / warnings will only be raised for public members. Which is not the case for the method m(). The reason why the error is raised for the class, and not for the method. --> if you change the Javadoc preference and set it to default, then the method's Javadoc comment will be flagged. 2- this behavior is coherent with Sun's Javadoc tool. Using your sample with default settings, use Project --> Generated Javadoc (using the default 1.4.2 JRE) to generate the Javadoc. You'll notice the "warning - Tag @link: reference not found: Inner" message. 3- workaround. To get rid of the class's Javadoc error / warning whatever the default settings are, simply put the Inner class fully qualified named, so that the comment reads: {@link otherpkg.C.Inner} 4- The real issue here is that content assist should insert the fully qualified name, instead of just inserting the name.
>2- this behavior is coherent with Sun's Javadoc tool. Yeah, but it's a bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4464323 >4- The real issue here is that content assist should insert the fully qualified >name, instead of just inserting the name. No. We insert according to the code assist preference. If you want full qualifications then change the preferences. We won't adjust to wrork around http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4464323
(In reply to comment #3) > >2- this behavior is coherent with Sun's Javadoc tool. > Yeah, but it's a bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4464323 > > >4- The real issue here is that content assist should insert the fully qualified > >name, instead of just inserting the name. > No. We insert according to the code assist preference. If you want full > qualifications then change the preferences. We won't adjust to wrork around > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4464323 > You're right. My fault, I forgot this point (see also bug 149013) when looking at this bug with Eric.
Keep this bug as REMIND waiting for a change on Sun's bug...
Reopen as REMIND is deprecated...
Can this be fixed in 3.4? We just 'broke' the N20070703-0010 build again as the Javadoc tool complained about the missing qualification, and we didn't get warned in the IDE. The compiler just need to have the same behavior as the Javadoc command. At least for source compliance 1.1 - 1.6 until Sun changes anything. Our case was: public class IntroduceParameterObjectDescriptor { public static class Parameter { /** * The position in the new method signature depends on the position in the array passed to * {@link IntroduceParameterObjectDescriptor#setParameters(Parameter[])} */ public int getIndex() { return 0; } } } Should be {@link IntroduceParameterObjectDescriptor#setParameters(IntroduceParameterObjectDescriptor.Parameter[])}
+1. I don't think it's smart to mimic a bug in Sun's Javadoc tool.
>+1. I don't think it's smart to mimic a bug in Sun's Javadoc tool. That was rather confusing. What I meant is we should also report the warning like the Javadoc tool because at the end the user has to use the Javadoc tool and runs into the problem. The Sun bug is quite old and will probably not be fixed soon.
(In reply to comment #9) > >+1. I don't think it's smart to mimic a bug in Sun's Javadoc tool. > That was rather confusing. What I meant is we should also report the warning > like the Javadoc tool because at the end the user has to use the Javadoc tool > and runs into the problem. The Sun bug is quite old and will probably not be > fixed soon. > Agreed (that it was confusing ;-) and to keep the warning reported by the compiler...) However, the sample in comment 7 looks completely different than the one described in comment 0. This bug initially complains that there was a warning in class comment; in comment 7, no warning is reported although Javadoc tool does. So, I would prefer have separate bug for this new problem. Martin, can you open it? Thanks
I filed a new bug 195374.
Using Eclipse SDK Version: 3.3.0 Build id: I20070821-0800 Observed behavior summary 1.4.2 Level Eclipse - compliance 1.4: 2 warnings (Javadoc: Invalid member type qualification) Sun JDK 1.4.2: 2 warnings (Tag @link: reference not found: Inner) IBM JDK 1.4.2: 2 warnings (Tag @link: Class or Package not found: Inner) 5.0 Level Eclipse - compliance 5.0: no warning Sun JDK 1.5: no warning IBM JDK 1.5: no warning JRockit 1.5: no warning
So it looks like this one is fixed. Eric, what change fixed the problem ?
(In reply to comment #13) bug 176027, integrated into 3.3 M6
*** This bug has been marked as a duplicate of bug 176027 ***
