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

Gunnar Morling gunnar at hibernate.org
Wed Jun 28 16:24:55 EDT 2017

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

More information about the hibernate-dev mailing list