Community
Participate
Working Groups
public class Test { /** @see Object#equals */ public boolean equals(Object obj) { return super.equals(obj); } } @@@@ The above should not flag "equals cannot be resolved or is not a field". See fith exampe on: http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html#seeexamples
fifth :D
Frederic - pls double check javadoc tool expectation before proceeding. The example seems to allow it, but the further spec for @see tag doesn't mention it.
Using Javadoc (1.4.2) creates: @@@@ equals public boolean equals(Object obj) See Also: Object.equals(java.lang.Object) @@@@ I used Eclipse and checked "rt.jar" in the creation wizard.
This is correct, compiler should accept this syntax. Here's the extract of spec which relates about this: "... If any method or constructor is entered as a name with no parentheses, such as getValue, and if there is no field with the same name, the Javadoc tool will correctly create a link to it, but will print a warning message reminding you to add the parentheses and arguments. If this method is overloaded, the Javadoc tool will link to the first method its search encounters, which is unspecified. ..." I missed it while implementing it...
*** Bug 54893 has been marked as a duplicate of this bug. ***
*** Bug 56754 has been marked as a duplicate of this bug. ***
Well, first I also thought it should not warn me (I even filed bug 56754) but I changed my mind. Reason: the javadoc tool automatically replaces methods that come without (...) with the first he finds, e.g. a(int, float); a(); a(String); /** * @see #a */ will appear in Javadoc as: /** * @see <link to a(int, float)> */ Hence, #a does not denote all a's but will be replaced by exactly one of the available methods. I therefore vote to produce a warning for method references that have no (...).
Thanks Daniel for the feedback. I also agree that regarding Javadoc tool behavior, it would be better to let compiler warns user on this kind of syntax. To make user life easier, perhaps a quick-fix could be to add all possible @see tags. In your example, then we would have after the quick-fix: /** * @see #a(int, float) * @see #a() * @see #a(String) */ If all CCs agree, I will close this bug as RESOLVED INVALID...
Change to a different warning is fine with me; something along the lines "ambiguous type/field reference". Having an accompanying quick fix would be appreciated but I'd consider it "if time permits" for 3.0. This PR is not about _not_ flagging a warning, but about an flagging an appropriate warning, therefore RESOLVED-FIXED would be the right resolution in my opinion =D
Finally, I'll keep it this bug opened to track warning message change. I also propose not to display this warning if there's no ambiguity on method name. For example, your initial example should not produce any warning as there's only one method equals on Object. It would not make sense that compiler warns user on ambiguous reference although there was only one method, would it?
Yes, correct. Though I'd say this is the luxury solution since AFAIK the Javadoc reference specified that you either have to use "random text" or a _valid_ reference.
Fixed. Luxury solution was implemented (perhaps I have expensive tastes ;-): 1) message is only displayed when several methods exist on referenced class 2) message has been changed to: "Javadoc: {0} is an ambiguous method reference or is not a field" Note that in this case, this is now a JavadocMessageSend AST node which is stored in Javadoc.references array instead of JavadocFieldReference. Similarily, it's a MethodRef which replace initial Memberref stored in @see tagElement fragments. However, binding for this replaced MethodRef is null as we haven't enough information for the arguments... [jdt-core-internal] New message [508] added in IProblem/message.properties, New method javadocAmbiguousMethodReference(FieldReference, int) added in ProblemReporter, JavadocFieldReference.internalResolveType(Scope) modified to take into account possible method reference when field reference is not found, Javadoc resolve(ClassScope) and resolve(MethodScope) methods modified to replace field reference by message send when unique method exists on referenced type. Test cases added in JavadocTestMixed
*** Bug 58797 has been marked as a duplicate of this bug. ***
Verified in 200405180816
