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 Tue, 22 Oct 2013 19:11:28 GMT
Well your comment makes sense anyway...


2013/10/21 Henri Yandell <flamefew@gmail.com>

> On Mon, Oct 21, 2013 at 12:28 PM, 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?
> >
>
> Or I could need sleep. I was on the subject of deprecating the time
> package. :(
>
> Hen
>



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