Why the RetentionPolicy for @deprecated is RUNTIME?

Question

Why at runtime is anyone interested in knowing that a method is deprecated? Can some provide me with some examples?

Answer 1

You're assuming that @deprecated is only of interest in the compile phase (IDE, compiler), but its not a stretch to imaging instrumentation scenarios where you require that information.

For example, an IDE can inform you of the number of call sites for a deprecated method, but how would you go about determining the percentage of time your application spends in deprecated methods?

Answer 2

Imagine you compile MyClass.class with deprecated methods. If your @Deprecated annotations got lost, your IDE or compiler couldn't warn you when you call those methods from another class.

Answer 3

One's runtime is another one's design time, e.g. when writing code that uses an API.

Answer 4

Good question, and I'm stretching to come up with a convincing scenario. All I've got is that I could imagine a application which used a classloader which didn't allow the use of deprecated code. This would require RetentionPolicy.RUNTIME.

That's all I've got...

Answer 5

Couple practical uses that come to mind:

With Velocity you can have a custom Uberspector which logs the actual calls from Velocity templates to any deprecated method and then just by reading the log you can see where the method is used and you can go and edit it out.

With Wicket you can have a security policy which disallows instantiating any class based on the .class contents so it could be possible to make a system which prevents the instantiation of @Deprecated classes if you're not an admin.

Answer 6

There are some frameworks and tools that instantiate objects to work with them.

For example, many JavaBean UI editors create instances of the beans and interact with them as the user manipulates the UI they're designing.

Having the @Deprecated annotation available at runtime allows tools such as this to flag deprecated methods, events, properties for the user.