Community
Participate
Working Groups
Javadoc comment support will come soon in JDT-Core, but it will be applied only on Javadoc comment (ie. /** comment */). However, it seems that in some cases, we'd need also to verify some Javadoc tags even if they are not put in a Javadoc comment. Typically when using action Source->Override/Implement Methods..., if I select a method from an interface then the inserted code will be as follow: /* (non-Javadoc) * @see org.eclipse.jdt.core.IMyInterface#myMethod(int, int) */ public void myMethod(int a, int b) { // TODO Auto-generated method stub } In this case, it would be useful to verify that the reference used in this @see tag is correct and also match the method below...
Updating title
*** Bug 51953 has been marked as a duplicate of this bug. ***
I think that you can use the flag not to look for missing JavaDoc comments, but to look for missing *comments*. Someone who has put a non-JD comment above a method has usually done so for a good reason, so /* internal method */ public void thing() could well have done so to avoid generating a JavaDoc comment. I think the ones that should be looked for are types/methods/fields that don't have a comment above them; rather than introspecting a JD tag inside an ordinary comment. Alternatively, it could be a preference option (warn missing JavaDoc/warn missing comment) which I would be just as happy with.
Just a general question: Why doesn't ContentAssist insert a Javadoc-comment here in the first place? I'd much prefer it that way, since I usually add Javadoc-comments to overwritten functions too and explain what's different etc.. .
I'd prefer it to generate the non-JD comment on overridden methods as opposed to a JD one. Most of the time, an overridden method has the same intent and the JD should explain the intent, not the implementation. However, an option to say 'generate JD comments or non-JD methods for overriden methods' in the code generation might solve both of these desires. The main reason why it's not standard practice to put JD comments in overriden methods that do the same thing is to solve the problem of maintaining two descriptions of the same method intent.
Post 3.0
Reopen to change state to WONTFIX
We'll not implement this behavior. Instead it would be better to have a specific warning to say that block comment contains tags (see bug 52116)
*** Bug 115298 has been marked as a duplicate of this bug. ***
