Bugzilla – Full Text Bug Listing
| Summary: | Warning on Javadoc @see when referencing generic method with multiple bounds | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mauro Molinari <mauromol> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | markus.kell.r, Olivier_Thomann, zorzella |
| Version: | 3.6.2 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
Reproduced in HEAD. You have to enable Javadoc processing for the project and enable "Malformed Javadoc comments" and "Validate tag arguments". This is the same issue. Once bug 341795 is fixed, this will also be fixed. *** This bug has been marked as a duplicate of bug 341795 *** (In reply to comment #2) > This is the same issue. Once bug 341795 is fixed, this will also be fixed. > > *** This bug has been marked as a duplicate of bug 341795 *** I'm not sure that's really the same issue. Javadoc references should use the erasure of the method parameter types, so no type inference should be necessary in that situation. (In reply to comment #3) > I'm not sure that's really the same issue. Javadoc references should use the > erasure of the method parameter types, so no type inference should be necessary > in that situation. If this is not the same issue, this will be reopened. This first warning still happens in Kepler and Luna. Also, it is not Java7 specific (as bug 341795 would suggest). By the way, I'm not certain whether the warning is wrong or the actual syntax of @see is wrong for this specific case, however it's the one produced by JDT code assist. Even if I searched on the net, I was not able to determine whether it's correct or not. I didn't try the Javadoc tool to see what it says. With master, I only get a single problem "Javadoc: The method setaMethod(T) in the type A is not applicable for the arguments (B)" on * @see #setaMethod(B) This warning is wrong. http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html still doesn't clearly specify this, but all evidence tells that the erasure of a type variable should be used (which is "B" here). Javadoc.exe from JDK 8 also accepts the reference. Interestingly, the bug vanishes once I turn "interface A" into "interface A<E>". I don't even have to declare method "void take(E e);" and a reference "@see #take(Object)" to prove the point... Note that Ctrl-Clicking the method works properly, and that, unless there are overloads, it's possible to work around this issue by using the syntax with no params specified. Here's an annotated rundown of the issue:
************************************
public abstract class JavadocMultipleBoundsIssue {
abstract <T extends CharSequence & Runnable> void foo(T t);
/**
* This first one is what Eclipse's Ctrl-space completion proposes, but it
* results in a "not applicable for the arguments" warning (note that
* Ctrl-Clicking it works correctly):
*
* See {@link #foo(CharSequence)}
*
* This second one is "as valid" as the one Eclipse suggests, and it also
* resutls in the analogous warning (note that Ctrl-Clicking it also works
* correctly):
*
* See {@link #foo(Runnable)}
*
* This would be if one tried to use the entire string that defines the
* multiple bounds. Now you end up with a "Invalid parameters declaration"
* warning (note that Ctrl-Clicking it does not work at all):
*
* See {@link #foo(CharSequence & Runnable)}
*
* Finally, this actually works, but, of course, is not ideal, and would not
* be an option if there were multiple overloads of {@code foo}.
*
* See {@link #foo}
*/
void bar() {}
}
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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: M20110210-1200 See steps to repro Reproducible: Always Steps to Reproduce: 1. write the following classes: public interface A { /** * @see #setaMethod(B) */ <T extends B & C> T getaMethod(); /** * @see #getaMethod() */ <T extends B & C> void setaMethod(T param); } public class B { } public interface C { } 2. look at the rows where I use @see in the Javadoc; this is what I see: - on the first @see in A: Javadoc: Bound mismatch: The generic method setaMethod(T) of type A is not applicable for the arguments (B). The inferred type B is not a valid substitute for the bounded parameter <T extends B & C> - on the second @see in A: Javadoc: Bound mismatch: The generic method getaMethod() of type A is not applicable for the arguments (). The inferred type B is not a valid substitute for the bounded parameter <T extends B & C>