[hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?

[Steve Ebersole]

On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero <sanne at 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/SearchIntegrator.html#getIndexBinding-java.lang.Class-


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