On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero <sa...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
