Bug 89807 - Outliner should recognize @Deprecated annotation
Summary: Outliner should recognize @Deprecated annotation
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-31 06:13 EST by Philipe Mulet CLA
Modified: 2006-03-28 12:14 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2005-03-31 06:13:28 EST
Build 20050330

Along the line of bug 83643, last comment, the outliner will not render
@Deprecated annotations as deprecated, since the model did not encode this
information into the modifier flags.

The reason for it is that this would require some resolution (could be another
@Deprecated annotation type out there).
Comment 1 Philipe Mulet CLA 2005-03-31 06:14:12 EST
Given the outliner has the DOM AST anyway, it could figure out the information
and present it to the user.
Comment 2 Dirk Baeumer CLA 2005-03-31 07:45:15 EST
Philippe, this doable for the Outline however not for other JDT views. The
problem is that we show the deprecate information (strike through of the icon)
in all Java views (e.g. package explorer, type hiararchy, ...) and they don't
have an AST around to compute the information.
Comment 3 Dirk Baeumer CLA 2005-04-28 13:41:39 EDT
Philippe only doing this for the outliner will ask for more PRS since users will
miss it in the package explorer, browsing view, search result, .... What's about
assuming that @Deprecate always is a real deprecate. If somebody redefines it he
is stupid anyways.
Comment 4 Philipe Mulet CLA 2005-04-28 18:10:15 EDT
I had guessed you would suggest cheating.
This would only be a custom hack for the model; but this means you couldn't tell
the difference, and this could induce discrepancies between model reconcile and
build time if one does redefine the offending annotation type.

Jerome - I think this is the best we can do for 3.1, and will solve 99% of the
problem. However, the model has to do it on its own, since the compiler support
is only triggered during resolution (i.e. too late in your case).
Comment 5 sunfish CLA 2005-12-08 14:15:44 EST
Any more work on this? This thread is pretty old, but the bug still exists. I find it annoying to have to add a javadoc comment /** @deprecated */ after I've already annotated a field/method as @Deprecated, just to get eclipse to show it correctly in the outline view.

build I20051102-1600
Comment 6 Philipe Mulet CLA 2006-02-20 06:21:30 EST
Agree we should solve this for 3.2. Cheating is likely the best we can do (i.e. since we do not resolve, simply assume presence of @Deprecated means it is deprecated).
Comment 7 Jerome Lanneluc CLA 2006-03-27 11:24:31 EST
Changed SourceElementParser#notifySourcElementRequestor(*) to check if the declaration is annotated with an annotation with the "Deprecated" simple name.

Added regression tests CompilationUnitTests#testDeprecatedFlags07/09.
Comment 8 Maxime Daniel CLA 2006-03-28 12:14:36 EST
Verified for 3.2M6 using build I20060328-0010.