Community
Participate
Working Groups
When I change or set the visibility of a class to default (package visible), Eclipse (with JavaDoc warnings enabled and scope set to protected) JavaDoc warnings produce warnings for all {@link} and @see reference on public methods in this type. Valid Example: public class Example1 { public void foo() { } /** * Like {@link #foo()} but with bar. * @see #foo() */ public void bar() { } } Invalid Example: class Example2 { public void foo() { } /** * Like {@link #foo()} but with bar. * @see #foo() */ public void bar() { } } So in Example2 Eclipse produces warnings for the @link and the @see tag saying: Javadoc: 'protected' visibility for malformed doc comments hides this 'default' reference IMHO this is a bug as there is nothing wrong here. There is no public API pointing to a refence of a scope not included in the JavaDoc. If you treat the visibility of these methods as default for deciding that they should not be referenced in public methods (what is fine so far) then you need to consider also the referencing methods as default visbility. Be aware that also this is not redering a warning as it is perfectly fine: public class Example3 { void foo() { } /** * Like {@link #foo()} but with bar. * @see #foo() */ void bar() { } } By reducing the visibility from public to default I do not want to be forced to remove valuable information as my JavaDoc (of course the example has no value and is just nonsense). However these wrong warnings imply users to do so.
Please also consider that when overriding such methods it is not possible to change the visibitlity of the method from public to default just because the class has default visibility to workaround the bug in all cases.
I have the same problem with the JavaDoc of package-private classes. In my case, I have two classes in the same package as shown below: final class ExampleA { } /** * This references {@link ExampleA}. */ final class ExampleB { } This should be fine as well to my knowledge because everything here is just package-private and even final.
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.