Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?
On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
The @Deprecated annotation is also evolving; for example in Java 9 it
will have some additional attributes:
- http://download.java.net/java/jdk9/docs/api/java/lang/Deprecated.html
The only additional data point I had proposed on @EndOfLife is the removal
version[1]. A custom one did afford the opportunity to better define
version, but that is obviously hard to do in a JDK annotation.
More improvements have been discussed, I'm sure the JDK team
would
love to hear about your additional needs.
Do you have an example of why people complain about our current usage?
Again the reason is that it introduces compilation warnings that (1) show
in the IDE and (2) cannot be "fixed" (in the cases I am talking about)
without turning off warnings in which case they miss *all* warnings.
If some Hibernate user is confused about how to fix his code, IMO he
has a point but we can address that w/o new annotations:
How do you fix a deprecation on something with no replacement?
the
@Deprecated annotation is meant to be used together with the
@deprecated javadoc tag, which should explain what to do.
Example:
-
https://docs.jboss.org/hibernate/search/5.8/api/org/hibernate/search/spi/...
Yes we understand how @Deprecated/@deprecated work ;) And in fact we do
the same thing. *However* there are cases where we deprecate something
with no replacement whatsoever. Sure `@Deprecated#forRemoval` helps with
that to a degree; but (1) that's Java 9 and (2) it still does not help
users in the case described - again how do they "fix" that warning?
And again to be clear... I personally agree that @Deprecated is the correct
solution. I am just opening it up for discussion
[1] https://hibernate.atlassian.net/browse/HHH-11836