Community
Participate
Working Groups
2.1 If you reference a deprecated field, the hover containing the compiler warning that says: 'The method xx of type yy is deprecated'. I have to open the reference to see the reason. It would be useful if the message also contains the message after the @deprecated tag, e.g. /** * @deprecated Use ASTNodes.asString(name) instead */
This would be indeed interesting to obtain, but quite expensive to compute. We mostly compile against binaries, for which we only have a deprecation bit set. Finding out some reason for the deprecation would require to find the attached source, parse it so as to extract the info you want. If classfiles were holding onto this information, then this would be quite easy... Will tag as later, since it is a valid suggestion anyway.
The other approach would be to do this in the UI. The hover is invoked on delay, so we can afford it to be a bit expensive. Of course, as a side note, having Javamodel or the AST to return the Javadoc tags would be cool.
To alleviate the problem, I've set the Hover Key Modifier for Javadocs to "Shift" (in Preferences > Java > Editor > Hovers). Now, I can at least hold the Shift key to see a sensible warning when I hover over a deprecated java element.
Can this be reopend for 3.1 consideration?
*** Bug 73519 has been marked as a duplicate of this bug. ***
Since 3.0 Javadoc comments are not only text bug have children (JavadocTag) in DOM AST nodes hierarchy. So, UI can "easily" get text for @deprecated tag. Markus, ok to move this bug to JDT/UI component and let you to decide whether it could be reopened for 3.1?
I discussed this with JDT/Text (who implement the hovers). We won't implement this in UI land, since it would lead to inconsistencies (hover is only available in editor, but not in Problems view), and it would also be too expensive to compute on demand (we would have to parse the target type and possibly supertypes to find the message). Why don't you add a compiler preference to let users decide whether they want to pay a perfomance penalty for this feature?
This cannot be a compiler preference as parser does not take care about text after tags. It only verifies syntax and does not matter about description which have no specific expected syntax... Furthermore, JDT/Core currently provides necessary information in DOM AST hierarchy to solve this problem. The only question is about hover behavior: does it need to parse the file which defines the deprecated reference and build the AST Node hierarchy to get this piece of information? So, I think it should be a JDT/UI or JDT/Text preference, not a compiler one.
We could do it in UI land if bug 169995 got fixed.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
.
*** Bug 339325 has been marked as a duplicate of this bug. ***
*** Bug 382725 has been marked as a duplicate of this bug. ***
If it is expensive to compute, could we add a "link" entry (similar to the "Add suppress warnings entry") to see the deprecation Javadoc? The code-complete form displays Javadoc when it is being used, could that possibly be leveraged for hover? (I wouldn't be surprised if not, since they could be provided by completely separate plug-ins, for all I know - just a suggestion)
Eclipse currently displays javadoc when hovering over fields / methods that are not deprecated, so adding the @Deprecated annotation actually loses functionality.
Are there any plans to follow this after all these years?
(In reply to Marvin Fröhlich from comment #16) > Are there any plans to follow this after all these years? High quality patches are welcome.
*** Bug 532358 has been marked as a duplicate of this bug. ***
