commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Date Fri, 25 Oct 2013 17:41:30 GMT
I'm okay with removing the @deprecated tag from the said methods. Maybe we
can just add it as <strong>Note:</strong> to the main JavaDoc, or something
like that?


2013/10/25 Matt Benson <gudnabrsam@gmail.com>

> Do we want to go with Sebastian's suggestion here, or discuss further?  I
> wouldn't call the matter resolved, and it does indeed look a bit irritating
> to see deprecation warnings in [lang]'s *own* code.
>
> Matt
>
>
> On Tue, Oct 22, 2013 at 3:00 PM, sebb <sebbaz@gmail.com> wrote:
>
> > On 22 October 2013 20:55, Matt Benson <gudnabrsam@gmail.com> wrote:
> > > On Tue, Oct 22, 2013 at 2:49 PM, sebb <sebbaz@gmail.com> wrote:
> > >
> > >> On 21 October 2013 20:28, Henri Yandell <flamefew@gmail.com> wrote:
> > >> > On Mon, Oct 21, 2013 at 7:29 AM, sebb <sebbaz@gmail.com> wrote:
> > >> >
> > >> >> On 21 October 2013 11:52, Benedikt Ritter <beneritter@gmail.com>
> > wrote:
> > >> >> >
> > >> >> >
> > >> >> > Send from my mobile device
> > >> >> >
> > >> >> >> Am 21.10.2013 um 03:46 schrieb sebb <sebbaz@gmail.com>:
> > >> >> >>
> > >> >> >>> On 20 October 2013 15:03, Benedikt Ritter <britter@apache.org>
> > >> wrote:
> > >> >> >>> I agree. If we don't deprecate it now, and agree
to release the
> > next
> > >> >> major
> > >> >> >>> version targeting Java 7, we would remove those methods
without
> > ever
> > >> >> >>> mentioning it before.
> > >> >> >>
> > >> >> >> That's not how I see it working.
> > >> >> >>
> > >> >> >> I think the deprecations should be added once the code
requires
> a
> > >> >> >> minimum of Java 7.
> > >> >> >> Later on, the deprecated methods are removed if required
(they
> > could
> > >> be
> > >> >> left).
> > >> >> >>
> > >> >> >> In any case, removal of the deprecated methods is not
binary
> > >> >> >> compatible, so new package/Maven coords are needed.
> > >> >> >> In which case, it's not really a problem that the methods
are
> not
> > >> >> >> deprecated first.
> > >> >> >> It would be sufficient to note the replacements in the
release
> > notes.
> > >> >> >>
> > >> >> >> Deprecation is only useful to users of a library if there
is a
> > >> >> >> replacement they can use.
> > >> >> >
> > >> >> > There is a replacement as Hen has pointed out. What you're
saying
> > is
> > >> >> that the replacement has to be part of the library, right?
> > >> >>
> > >> >> Not necessarily, the replacement could be part of standard Java
> > classes.
> > >> >>
> > >> >> But I don't think it's right to require users to migrate to a
later
> > >> >> version of Java than is required by the library itself in order
to
> > >> >> avoid the deprecation warning.
> > >> >>
> > >> >> And as I already wrote, it's important that deprecation warnings
> are
> > >> >> removed (not suppressed) in the library itself.
> > >> >> That is necessary to show that the deprecation makes sense.
> > >> >
> > >> >
> > >> > What's your solution, Sebb, to indicate that we plan to remove this
> > code
> > >> in
> > >> > 4.0?
> > >>
> > >> That would work for me.
> > >>
> > >> What would?
> >
> > "indicate that we plan to remove this code in 4.0"
> >
> > >
> > >
> > >> > Hen
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> >
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message