commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
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 20:00:38 GMT
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
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message