> 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 <st...@hibernate.org>: > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
