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

[Steve Ebersole]

In this specific case that I am asking about Gunner we are specifically
talking about adding deprecations to 5.2 for things we know are changing or
going away in 6.0.  Think of it as an "upgrade path" hint - in prep for
moving to 6 a user could upgrade to the latest 5.2 and find all things that
are likely/possibly going to be a problem in the 6.0 upgrade.

For longer term deprecations where we are not sure of the exact version
things get removed... that is where i could possibly see this being useful


On Wed, Jun 28, 2017, 3:25 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> > 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
>