Re: [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  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 :
> > On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero 
> > 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

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

[Gunnar Morling]

> 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 :
> On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero 
> 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

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

[Christian Beikov]

I think a deprecation with @Deprecated should be enough/is more 
appropriate for this.


Mit freundlichen Grüßen,

*Christian Beikov*
Am 28.06.2017 um 16:45 schrieb Steve Ebersole:
> 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 
> 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 
>> 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 
>>> 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  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 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 
> 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@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
>

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

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

[Sanne Grinovero]

On 28 June 2017 at 18:32, Steve Ebersole  wrote:
>
> On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero 
> 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?

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/metadata/IndexedTypeDescriptor.html#getDynamicBoost--


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

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

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

[Steve Ebersole]

On Wed, Jun 28, 2017 at 12:12 PM Sanne Grinovero 
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

Re: [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  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 
> 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 
>> 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 
>>> 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  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 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 
> 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@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
>


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

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

[Steve Ebersole]

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

>>>
>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Vlad Mihalcea]

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

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

[Chris Cranford]

Personally I would stick to using @Deprecated and be explicit in the
javadoc. 

On 06/28/2017 05:56 AM, andrea boriero 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  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 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 
>> 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@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
>>
> ___
> 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

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

[Steve Ebersole]

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

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

[andrea boriero]

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

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

[Vlad Mihalcea]

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

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

[Steve Ebersole]

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