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
> 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
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
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/Depreca
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 @
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 als
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
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 complete
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 altern
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
ema
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
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 setResultTransfor
12 matches
Mail list logo
