9:15 a.m.
Per subject I wanted to come to a consensus as to how exact we want to be
in terms of continuing to add deprecations to 5.2 for ongoing 6.0 work.
Considering that these deprecations are meant to be a guide for users to
migrate to 6.0 I think we should try to be as complete as possible in this
effort, but wanted to hear other's views.
An alternative is the @EndOfLife annotation I have recently added to 6.0.
We could back port this annotation and use that instead; the reason being
that people complain when we deprecate something without being able to
specify its "replacement". This would be an option to do both. The
drawback is that this annotation obviously has no tie-in with javac - users
would have to go out of their way to find these.
2:55 a.m.
I would use the regular Java deprecation mechanism is just make sure
we write the plan in the Javadoc and the User Guide.
On example is Query#setResultTransformer:
If we didn't use deprecated here, and chose only @EndOfLife,
people might complain even more that they didn't ackowledged that this
method is going to be changed in future.
Vlad
On Tue, Jun 27, 2017 at 5:15 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
8:51 a.m.
Vald, while I personally completely agree with you that @Deprecated is the
proper approach (imo), some users do not. @EndOfLife offers a *possible*
alternative. Yes using @EndOfLife does not warn users of using deprecated
features unless they do something "extra" as I mentioned in my original
email.
The question is whether @EndOfLife is an appropriate "middle ground"
On Wed, Jun 28, 2017 at 4:56 AM andrea boriero <andrea(a)hibernate.org> wrote:
9:18 a.m.
The concept is good and we should apply it. Instead of @EndOfLife we could
use @Deprecating
as it suggests a continuing action has not finished yet, but the eventual
outcome is obvious.
Makes sense?
Vlad
On Wed, Jun 28, 2017 at 4:51 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
9:45 a.m.
A rose by any other name... I am fine with either name -
What we need to determine is whether the concept is valid, or if we just
keep with our current "deprecation strategy". In the past I have been
pretty insistent that @Deprecated is the proper approach. I am offering a
potential alternative to see what others think.
On Wed, Jun 28, 2017 at 9:18 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
12:11 p.m.
I would prefer to keep using @Deprecated as it doesn't help people
much to have to learn about new annotations and what semantic we think
they should have; also alternative annotations are unlikely to
integrate with tooling as nicely as the java.lang standard one.
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
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?
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: 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/...
Thanks,
Sanne
On 28 June 2017 at 15:45, Steve Ebersole <steve(a)hibernate.org> wrote:
12:32 p.m.
On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
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.
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?
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
1:21 p.m.
On 28 June 2017 at 18:32, Steve Ebersole <steve(a)hibernate.org> wrote:
Typically in such cases I'm grateful for an explanation.
Even stating among the lines of "we remove this feature offering no
replacement as it was a bad idea" is useful: at least I won't spend
hours trying to figure out where a new alternative method is possibly
hiding :)
For example in this case in Hibernate Search we explain that the whole
concept of "indexing time boosting" is being removed, pointing out to
users to look into query-time-boosting (they used to be two different
approaches to obtain a similar effect):
-
https://docs.jboss.org/hibernate/search/5.8/api/org/hibernate/search/meta...
And again to be clear... I personally agree that @Deprecated is the
correct
solution. I am just opening it up for discussion
Of course, and thanks for that :)
3:24 p.m.
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(a)hibernate.org>:
6:15 p.m.
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(a)hibernate.org> wrote:
2829
days inactive
2830
days old
12 comments
7 participants
participants (7)
-
andrea boriero -
Chris Cranford -
Christian Beikov -
Gunnar Morling -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea