there are cases where we deprecate something
with no replacement whatsoever
Ah, so you are using deprecation to give users a heads-up that some
API will be removed in a future release, but there's no replacement
available yet?
In that case I'd indeed go for a separate annotation such as your
@EndOfLife, as it's more an information point at this point in time
rather than some actionable warning. @Deprecated in my understanding
should only be used if there's an alternative available, as otherwise
I see how it creates frustration - users get a warning about using a
deprecated API without a way of addressing this warning.
Or, ideally, you'd add the replacement API already right now (so any
@Deprecated warnings can be acted on by users), but I reckon it's not
doable due to complexity etc.
2017-06-28 19:32 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev