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

[Sanne Grinovero]

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/SearchIntegrator.html#getIndexBinding-java.lang.Class-

Thanks,
Sanne


On 28 June 2017 at 15:45, Steve Ebersole <steve at hibernate.org> wrote:
> 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 at gmail.com>
> wrote:
>
>> 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 at hibernate.org>
>> wrote:
>>
>>> 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 at hibernate.org>
>>> wrote:
>>>
>>>> In my opinion deprecating something is useful only when we are able to
>>>> provide an alternative, not sure about the best approach in case we do not
>>>> have a current alternative.
>>>>
>>>> On 28 June 2017 at 08:55, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>>>>
>>>>> 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:
>>>>>
>>>>> >
>>>>> >  * @deprecated (since 5.2)
>>>>> >  * @todo develop a new approach to result transformers
>>>>> >  */
>>>>> > @Deprecated
>>>>> > Query<R> setResultTransformer(ResultTransformer transformer);
>>>>>
>>>>> 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 at hibernate.org>
>>>>> wrote:
>>>>>
>>>>> > 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.
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev