Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
I'm okay with removing the @deprecated tag from the said methods. Maybe we can just add it as Note: to the main JavaDoc, or something like that? 2013/10/25 Matt Benson > 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 wrote: > > > On 22 October 2013 20:55, Matt Benson wrote: > > > On Tue, Oct 22, 2013 at 2:49 PM, sebb wrote: > > > > > >> On 21 October 2013 20:28, Henri Yandell wrote: > > >> > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > > >> > > > >> >> On 21 October 2013 11:52, Benedikt Ritter > > wrote: > > >> >> > > > >> >> > > > >> >> > Send from my mobile device > > >> >> > > > >> >> >> Am 21.10.2013 um 03:46 schrieb sebb : > > >> >> >> > > >> >> >>> On 20 October 2013 15:03, Benedikt Ritter > > >> 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-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
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 wrote: > On 22 October 2013 20:55, Matt Benson wrote: > > On Tue, Oct 22, 2013 at 2:49 PM, sebb wrote: > > > >> On 21 October 2013 20:28, Henri Yandell wrote: > >> > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > >> > > >> >> On 21 October 2013 11:52, Benedikt Ritter > wrote: > >> >> > > >> >> > > >> >> > Send from my mobile device > >> >> > > >> >> >> Am 21.10.2013 um 03:46 schrieb sebb : > >> >> >> > >> >> >>> On 20 October 2013 15:03, Benedikt Ritter > >> 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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On 22 October 2013 20:55, Matt Benson wrote: > On Tue, Oct 22, 2013 at 2:49 PM, sebb wrote: > >> On 21 October 2013 20:28, Henri Yandell wrote: >> > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: >> > >> >> On 21 October 2013 11:52, Benedikt Ritter wrote: >> >> > >> >> > >> >> > Send from my mobile device >> >> > >> >> >> Am 21.10.2013 um 03:46 schrieb sebb : >> >> >> >> >> >>> On 20 October 2013 15:03, Benedikt Ritter >> 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On Tue, Oct 22, 2013 at 2:49 PM, sebb wrote: > On 21 October 2013 20:28, Henri Yandell wrote: > > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > > > >> On 21 October 2013 11:52, Benedikt Ritter wrote: > >> > > >> > > >> > Send from my mobile device > >> > > >> >> Am 21.10.2013 um 03:46 schrieb sebb : > >> >> > >> >>> On 20 October 2013 15:03, Benedikt Ritter > 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? > > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On 21 October 2013 20:28, Henri Yandell wrote: > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > >> On 21 October 2013 11:52, Benedikt Ritter wrote: >> > >> > >> > Send from my mobile device >> > >> >> Am 21.10.2013 um 03:46 schrieb sebb : >> >> >> >>> On 20 October 2013 15:03, Benedikt Ritter 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. > Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Well your comment makes sense anyway... 2013/10/21 Henri Yandell > On Mon, Oct 21, 2013 at 12:28 PM, Henri Yandell > wrote: > > > > > > > > > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > > > >> On 21 October 2013 11:52, Benedikt Ritter wrote: > >> > > >> > > >> > Send from my mobile device > >> > > >> >> Am 21.10.2013 um 03:46 schrieb sebb : > >> >> > >> >>> On 20 October 2013 15:03, Benedikt Ritter > 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
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On Mon, Oct 21, 2013 at 12:28 PM, Henri Yandell wrote: > > > > On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > >> On 21 October 2013 11:52, Benedikt Ritter wrote: >> > >> > >> > Send from my mobile device >> > >> >> Am 21.10.2013 um 03:46 schrieb sebb : >> >> >> >>> On 20 October 2013 15:03, Benedikt Ritter 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
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On Mon, Oct 21, 2013 at 7:29 AM, sebb wrote: > On 21 October 2013 11:52, Benedikt Ritter wrote: > > > > > > Send from my mobile device > > > >> Am 21.10.2013 um 03:46 schrieb sebb : > >> > >>> On 20 October 2013 15:03, Benedikt Ritter 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? Hen
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On 21 October 2013 11:52, Benedikt Ritter wrote:
>
>
> Send from my mobile device
>
>> Am 21.10.2013 um 03:46 schrieb sebb :
>>
>>> On 20 October 2013 15:03, Benedikt Ritter 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.
>>
>>> Thanks for adding the suppressions, btw :-)
>>>
>>> Benedikt
>>>
>>>
>>> 2013/10/19 Henri Yandell
>>>
My tuppence:
Lang 3 targets Java 6, but users can go upgrade to Java 7. So the
deprecated warnings are actionable by changing your code to Java 7.
Internal use - would this lead to warnings? As long as it isn't leading to
warnings, updating internal is only a best practice and in this case
wouldn't be possible as we're the ones stuck on Java 6.
Hen
> On Fri, Oct 18, 2013 at 9:25 AM, Matt Benson wrote:
>
> Perhaps we need some other kind of pre-deprecation convention.
>
> Matt
>
>
>> On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
>>
>> When adding an @depecrated annotation, please add the version in which
>> the code was deprecated.
>>
>> Also, although the comment provides an alternative method, it's not
>> actually available until Java 7.
>> As Lang currently targets Java 6, that is not helpful to end users.
>> How are they supposed to avoid the warnings?
>> Also, Lang code itself uses the deprecated code.
>> When deprecating methods, the first thing that should be changed is
>> internal uses.
>> That helps ensure that the replacement works OK.
>>
>> [It's OK for test code to use deprecated methods]
>>
>> I think we need to either provide new methods which are available with
>> Java 1.6, or delay the deprecation until the code requires Java 7 as
>> minimum.
>>
>>> On 14 October 2013 19:36, Benedikt Ritter wrote:
>>> Hi Matt,
>>>
>>> (fired the last one without adding my comment :-)
>>>
>>>
>>> 2013/10/14 Benedikt Ritter
>>>
2013/10/14 Matt Benson
> Hi Benedikt, see inline:
>
>
>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>>
>> Author: britter
>> Date: Mon Oct 14 18:15:39 2013
>> New Revision: 1532011
>>
>> URL: http://svn.apache.org/r1532011
>> Log:
>> Deprecate methods that are available in Java 7's
java.lang.Objects
>>
>> Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>>
>> Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> URL:
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
==
>> ---
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> (original)
>> +++
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> Mon Oct 14 18:15:39 2013
>> @@ -199,6 +199,8 @@ public class ArrayUtils {
>> * @param array1 the left hand array to compare, may be
> {@code
> null}
>> * @param array2 the right hand array to compare, may be
> {@code
> null}
>> * @return {@code true} if the arrays are equal
>> + * @deprecated this method has been replaced by {@code
>> java.util.Objects.deepEqua
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Send from my mobile device
> Am 21.10.2013 um 03:46 schrieb sebb :
>
>> On 20 October 2013 15:03, Benedikt Ritter 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?
>
>> Thanks for adding the suppressions, btw :-)
>>
>> Benedikt
>>
>>
>> 2013/10/19 Henri Yandell
>>
>>> My tuppence:
>>>
>>> Lang 3 targets Java 6, but users can go upgrade to Java 7. So the
>>> deprecated warnings are actionable by changing your code to Java 7.
>>>
>>> Internal use - would this lead to warnings? As long as it isn't leading to
>>> warnings, updating internal is only a best practice and in this case
>>> wouldn't be possible as we're the ones stuck on Java 6.
>>>
>>> Hen
>>>
>>>
On Fri, Oct 18, 2013 at 9:25 AM, Matt Benson wrote:
Perhaps we need some other kind of pre-deprecation convention.
Matt
> On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
>
> When adding an @depecrated annotation, please add the version in which
> the code was deprecated.
>
> Also, although the comment provides an alternative method, it's not
> actually available until Java 7.
> As Lang currently targets Java 6, that is not helpful to end users.
> How are they supposed to avoid the warnings?
> Also, Lang code itself uses the deprecated code.
> When deprecating methods, the first thing that should be changed is
> internal uses.
> That helps ensure that the replacement works OK.
>
> [It's OK for test code to use deprecated methods]
>
> I think we need to either provide new methods which are available with
> Java 1.6, or delay the deprecation until the code requires Java 7 as
> minimum.
>
>> On 14 October 2013 19:36, Benedikt Ritter wrote:
>> Hi Matt,
>>
>> (fired the last one without adding my comment :-)
>>
>>
>> 2013/10/14 Benedikt Ritter
>>
>>>
>>>
>>>
>>> 2013/10/14 Matt Benson
>>>
Hi Benedikt, see inline:
> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>
> Author: britter
> Date: Mon Oct 14 18:15:39 2013
> New Revision: 1532011
>
> URL: http://svn.apache.org/r1532011
> Log:
> Deprecate methods that are available in Java 7's
>>> java.lang.Objects
>
> Modified:
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>
> Modified:
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> URL:
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>>> ==
> ---
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> (original)
> +++
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> Mon Oct 14 18:15:39 2013
> @@ -199,6 +199,8 @@ public class ArrayUtils {
> * @param array1 the left hand array to compare, may be
{@code
null}
> * @param array2 the right hand array to compare, may be
{@code
null}
> * @return {@code true} if the arrays are equal
> + * @deprecated this method has been replaced by {@code
> java.util.Objects.deepEquals(Object, Object)} and will be
> + * removed from future releases.
> */
> public static boolean isEquals(final Object array1, final
Object
> array2) {
> return new EqualsBuilder().append(array1,
> array2).isEquals();
>
> Modified:
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> URL:
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
On 20 October 2013 15:03, Benedikt Ritter 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.
> Thanks for adding the suppressions, btw :-)
>
> Benedikt
>
>
> 2013/10/19 Henri Yandell
>
>> My tuppence:
>>
>> Lang 3 targets Java 6, but users can go upgrade to Java 7. So the
>> deprecated warnings are actionable by changing your code to Java 7.
>>
>> Internal use - would this lead to warnings? As long as it isn't leading to
>> warnings, updating internal is only a best practice and in this case
>> wouldn't be possible as we're the ones stuck on Java 6.
>>
>> Hen
>>
>>
>> On Fri, Oct 18, 2013 at 9:25 AM, Matt Benson wrote:
>>
>> > Perhaps we need some other kind of pre-deprecation convention.
>> >
>> > Matt
>> >
>> >
>> > On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
>> >
>> > > When adding an @depecrated annotation, please add the version in which
>> > > the code was deprecated.
>> > >
>> > > Also, although the comment provides an alternative method, it's not
>> > > actually available until Java 7.
>> > > As Lang currently targets Java 6, that is not helpful to end users.
>> > > How are they supposed to avoid the warnings?
>> > > Also, Lang code itself uses the deprecated code.
>> > > When deprecating methods, the first thing that should be changed is
>> > > internal uses.
>> > > That helps ensure that the replacement works OK.
>> > >
>> > > [It's OK for test code to use deprecated methods]
>> > >
>> > > I think we need to either provide new methods which are available with
>> > > Java 1.6, or delay the deprecation until the code requires Java 7 as
>> > > minimum.
>> > >
>> > > On 14 October 2013 19:36, Benedikt Ritter wrote:
>> > > > Hi Matt,
>> > > >
>> > > > (fired the last one without adding my comment :-)
>> > > >
>> > > >
>> > > > 2013/10/14 Benedikt Ritter
>> > > >
>> > > >>
>> > > >>
>> > > >>
>> > > >> 2013/10/14 Matt Benson
>> > > >>
>> > > >>> Hi Benedikt, see inline:
>> > > >>>
>> > > >>>
>> > > >>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>> > > >>>
>> > > >>> > Author: britter
>> > > >>> > Date: Mon Oct 14 18:15:39 2013
>> > > >>> > New Revision: 1532011
>> > > >>> >
>> > > >>> > URL: http://svn.apache.org/r1532011
>> > > >>> > Log:
>> > > >>> > Deprecate methods that are available in Java 7's
>> java.lang.Objects
>> > > >>> >
>> > > >>> > Modified:
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>> > > >>> >
>> > > >>> > Modified:
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > > >>> > URL:
>> > > >>> >
>> > > >>>
>> > >
>> >
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > >
>> >
>> ==
>> > > >>> > ---
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > > >>> > (original)
>> > > >>> > +++
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > > >>> > Mon Oct 14 18:15:39 2013
>> > > >>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
>> > > >>> > * @param array1 the left hand array to compare, may be
>> > {@code
>> > > >>> null}
>> > > >>> > * @param array2 the right hand array to compare, may be
>> > {@code
>> > > >>> null}
>> > > >>> > * @return {@code true} if the arrays are equal
>> > > >>> > + * @deprecated this method has been replaced by {@code
>> > > >>> > java.util.Objects.deepEquals(Object, Object)} and will be
>> > > >>> > + * removed from future releases.
>> > > >>> > */
>> > > >>> > public static boolean isEquals(final Object array1, final
>> > Object
>> > > >>> > array2) {
>> > > >>> > return new EqualsBuilder().append(array1,
>> > > array2).isEquals();
>> > > >>> >
>> > > >>> > Modified:
>> > > >>> >
>> > > >>>
>> > >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
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.
Thanks for adding the suppressions, btw :-)
Benedikt
2013/10/19 Henri Yandell
> My tuppence:
>
> Lang 3 targets Java 6, but users can go upgrade to Java 7. So the
> deprecated warnings are actionable by changing your code to Java 7.
>
> Internal use - would this lead to warnings? As long as it isn't leading to
> warnings, updating internal is only a best practice and in this case
> wouldn't be possible as we're the ones stuck on Java 6.
>
> Hen
>
>
> On Fri, Oct 18, 2013 at 9:25 AM, Matt Benson wrote:
>
> > Perhaps we need some other kind of pre-deprecation convention.
> >
> > Matt
> >
> >
> > On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
> >
> > > When adding an @depecrated annotation, please add the version in which
> > > the code was deprecated.
> > >
> > > Also, although the comment provides an alternative method, it's not
> > > actually available until Java 7.
> > > As Lang currently targets Java 6, that is not helpful to end users.
> > > How are they supposed to avoid the warnings?
> > > Also, Lang code itself uses the deprecated code.
> > > When deprecating methods, the first thing that should be changed is
> > > internal uses.
> > > That helps ensure that the replacement works OK.
> > >
> > > [It's OK for test code to use deprecated methods]
> > >
> > > I think we need to either provide new methods which are available with
> > > Java 1.6, or delay the deprecation until the code requires Java 7 as
> > > minimum.
> > >
> > > On 14 October 2013 19:36, Benedikt Ritter wrote:
> > > > Hi Matt,
> > > >
> > > > (fired the last one without adding my comment :-)
> > > >
> > > >
> > > > 2013/10/14 Benedikt Ritter
> > > >
> > > >>
> > > >>
> > > >>
> > > >> 2013/10/14 Matt Benson
> > > >>
> > > >>> Hi Benedikt, see inline:
> > > >>>
> > > >>>
> > > >>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
> > > >>>
> > > >>> > Author: britter
> > > >>> > Date: Mon Oct 14 18:15:39 2013
> > > >>> > New Revision: 1532011
> > > >>> >
> > > >>> > URL: http://svn.apache.org/r1532011
> > > >>> > Log:
> > > >>> > Deprecate methods that are available in Java 7's
> java.lang.Objects
> > > >>> >
> > > >>> > Modified:
> > > >>> >
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > > >>> >
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > > >>> >
> > > >>> > Modified:
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > > >>> > URL:
> > > >>> >
> > > >>>
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> > > >>> >
> > > >>> >
> > > >>>
> > >
> >
> ==
> > > >>> > ---
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > > >>> > (original)
> > > >>> > +++
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > > >>> > Mon Oct 14 18:15:39 2013
> > > >>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
> > > >>> > * @param array1 the left hand array to compare, may be
> > {@code
> > > >>> null}
> > > >>> > * @param array2 the right hand array to compare, may be
> > {@code
> > > >>> null}
> > > >>> > * @return {@code true} if the arrays are equal
> > > >>> > + * @deprecated this method has been replaced by {@code
> > > >>> > java.util.Objects.deepEquals(Object, Object)} and will be
> > > >>> > + * removed from future releases.
> > > >>> > */
> > > >>> > public static boolean isEquals(final Object array1, final
> > Object
> > > >>> > array2) {
> > > >>> > return new EqualsBuilder().append(array1,
> > > array2).isEquals();
> > > >>> >
> > > >>> > Modified:
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > > >>> > URL:
> > > >>> >
> > > >>>
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> > > >>> >
> > > >>> >
> > > >>>
> > >
> >
> ==
> > > >>> > ---
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > > >>> > (original)
> > > >>> > +++
> > > >>> >
> > > >>>
> > >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > > >>> > Mon Oct 14 18:15:39 2013
> > > >>> > @@ -149,6 +149,8 @@ public class ObjectUtils {
> > > >>> > * @param object1 the
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
My tuppence:
Lang 3 targets Java 6, but users can go upgrade to Java 7. So the
deprecated warnings are actionable by changing your code to Java 7.
Internal use - would this lead to warnings? As long as it isn't leading to
warnings, updating internal is only a best practice and in this case
wouldn't be possible as we're the ones stuck on Java 6.
Hen
On Fri, Oct 18, 2013 at 9:25 AM, Matt Benson wrote:
> Perhaps we need some other kind of pre-deprecation convention.
>
> Matt
>
>
> On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
>
> > When adding an @depecrated annotation, please add the version in which
> > the code was deprecated.
> >
> > Also, although the comment provides an alternative method, it's not
> > actually available until Java 7.
> > As Lang currently targets Java 6, that is not helpful to end users.
> > How are they supposed to avoid the warnings?
> > Also, Lang code itself uses the deprecated code.
> > When deprecating methods, the first thing that should be changed is
> > internal uses.
> > That helps ensure that the replacement works OK.
> >
> > [It's OK for test code to use deprecated methods]
> >
> > I think we need to either provide new methods which are available with
> > Java 1.6, or delay the deprecation until the code requires Java 7 as
> > minimum.
> >
> > On 14 October 2013 19:36, Benedikt Ritter wrote:
> > > Hi Matt,
> > >
> > > (fired the last one without adding my comment :-)
> > >
> > >
> > > 2013/10/14 Benedikt Ritter
> > >
> > >>
> > >>
> > >>
> > >> 2013/10/14 Matt Benson
> > >>
> > >>> Hi Benedikt, see inline:
> > >>>
> > >>>
> > >>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
> > >>>
> > >>> > Author: britter
> > >>> > Date: Mon Oct 14 18:15:39 2013
> > >>> > New Revision: 1532011
> > >>> >
> > >>> > URL: http://svn.apache.org/r1532011
> > >>> > Log:
> > >>> > Deprecate methods that are available in Java 7's java.lang.Objects
> > >>> >
> > >>> > Modified:
> > >>> >
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > >>> >
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > >>> >
> > >>> > Modified:
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > >>> > URL:
> > >>> >
> > >>>
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> > >>> >
> > >>> >
> > >>>
> >
> ==
> > >>> > ---
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > >>> > (original)
> > >>> > +++
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > >>> > Mon Oct 14 18:15:39 2013
> > >>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
> > >>> > * @param array1 the left hand array to compare, may be
> {@code
> > >>> null}
> > >>> > * @param array2 the right hand array to compare, may be
> {@code
> > >>> null}
> > >>> > * @return {@code true} if the arrays are equal
> > >>> > + * @deprecated this method has been replaced by {@code
> > >>> > java.util.Objects.deepEquals(Object, Object)} and will be
> > >>> > + * removed from future releases.
> > >>> > */
> > >>> > public static boolean isEquals(final Object array1, final
> Object
> > >>> > array2) {
> > >>> > return new EqualsBuilder().append(array1,
> > array2).isEquals();
> > >>> >
> > >>> > Modified:
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > >>> > URL:
> > >>> >
> > >>>
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> > >>> >
> > >>> >
> > >>>
> >
> ==
> > >>> > ---
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > >>> > (original)
> > >>> > +++
> > >>> >
> > >>>
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > >>> > Mon Oct 14 18:15:39 2013
> > >>> > @@ -149,6 +149,8 @@ public class ObjectUtils {
> > >>> > * @param object1 the first object, may be {@code null}
> > >>> > * @param object2 the second object, may be {@code null}
> > >>> > * @return {@code true} if the values of both objects are the
> > same
> > >>> > + * @deprecated this method has been replaces by {@code
> > >>> > java.util.Objects.equals(Object, Object)} in Java 7 and will
> > >>> > + * be removed from future releases.
> > >>> > */
> > >>> > public static boolean equals(final Object object1, final
> Object
> > >>> > object2) {
> > >>> > if (object1 == object2) {
> > >>> > @@ -195,6
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Perhaps we need some other kind of pre-deprecation convention.
Matt
On Fri, Oct 18, 2013 at 11:14 AM, sebb wrote:
> When adding an @depecrated annotation, please add the version in which
> the code was deprecated.
>
> Also, although the comment provides an alternative method, it's not
> actually available until Java 7.
> As Lang currently targets Java 6, that is not helpful to end users.
> How are they supposed to avoid the warnings?
> Also, Lang code itself uses the deprecated code.
> When deprecating methods, the first thing that should be changed is
> internal uses.
> That helps ensure that the replacement works OK.
>
> [It's OK for test code to use deprecated methods]
>
> I think we need to either provide new methods which are available with
> Java 1.6, or delay the deprecation until the code requires Java 7 as
> minimum.
>
> On 14 October 2013 19:36, Benedikt Ritter wrote:
> > Hi Matt,
> >
> > (fired the last one without adding my comment :-)
> >
> >
> > 2013/10/14 Benedikt Ritter
> >
> >>
> >>
> >>
> >> 2013/10/14 Matt Benson
> >>
> >>> Hi Benedikt, see inline:
> >>>
> >>>
> >>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
> >>>
> >>> > Author: britter
> >>> > Date: Mon Oct 14 18:15:39 2013
> >>> > New Revision: 1532011
> >>> >
> >>> > URL: http://svn.apache.org/r1532011
> >>> > Log:
> >>> > Deprecate methods that are available in Java 7's java.lang.Objects
> >>> >
> >>> > Modified:
> >>> >
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> >>> >
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> >>> >
> >>> > Modified:
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> >>> > URL:
> >>> >
> >>>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> >>> >
> >>> >
> >>>
> ==
> >>> > ---
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> >>> > (original)
> >>> > +++
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> >>> > Mon Oct 14 18:15:39 2013
> >>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
> >>> > * @param array1 the left hand array to compare, may be {@code
> >>> null}
> >>> > * @param array2 the right hand array to compare, may be {@code
> >>> null}
> >>> > * @return {@code true} if the arrays are equal
> >>> > + * @deprecated this method has been replaced by {@code
> >>> > java.util.Objects.deepEquals(Object, Object)} and will be
> >>> > + * removed from future releases.
> >>> > */
> >>> > public static boolean isEquals(final Object array1, final Object
> >>> > array2) {
> >>> > return new EqualsBuilder().append(array1,
> array2).isEquals();
> >>> >
> >>> > Modified:
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> >>> > URL:
> >>> >
> >>>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> >>> >
> >>> >
> >>>
> ==
> >>> > ---
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> >>> > (original)
> >>> > +++
> >>> >
> >>>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> >>> > Mon Oct 14 18:15:39 2013
> >>> > @@ -149,6 +149,8 @@ public class ObjectUtils {
> >>> > * @param object1 the first object, may be {@code null}
> >>> > * @param object2 the second object, may be {@code null}
> >>> > * @return {@code true} if the values of both objects are the
> same
> >>> > + * @deprecated this method has been replaces by {@code
> >>> > java.util.Objects.equals(Object, Object)} in Java 7 and will
> >>> > + * be removed from future releases.
> >>> > */
> >>> > public static boolean equals(final Object object1, final Object
> >>> > object2) {
> >>> > if (object1 == object2) {
> >>> > @@ -195,6 +197,8 @@ public class ObjectUtils {
> >>> > * @param obj the object to obtain the hash code of, may be
> {@code
> >>> > null}
> >>> > * @return the hash code of the object, or zero if null
> >>> > * @since 2.1
> >>> > + * @deprecated this method has been replaced by {@code
> >>> > java.util.Objects.hashCode(Object)} in Java 7 and will be
> >>> > + * removed in future releases
> >>> > */
> >>> > public static int hashCode(final Object obj) {
> >>> > // hashCode(Object) retained for performance, as hash code
> is
> >>> > often critical
> >>> > @@ -220,6 +224,8 @@ public class ObjectUtils {
> >>> > * @param objects the objects to obtain the has
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
When adding an @depecrated annotation, please add the version in which
the code was deprecated.
Also, although the comment provides an alternative method, it's not
actually available until Java 7.
As Lang currently targets Java 6, that is not helpful to end users.
How are they supposed to avoid the warnings?
Also, Lang code itself uses the deprecated code.
When deprecating methods, the first thing that should be changed is
internal uses.
That helps ensure that the replacement works OK.
[It's OK for test code to use deprecated methods]
I think we need to either provide new methods which are available with
Java 1.6, or delay the deprecation until the code requires Java 7 as
minimum.
On 14 October 2013 19:36, Benedikt Ritter wrote:
> Hi Matt,
>
> (fired the last one without adding my comment :-)
>
>
> 2013/10/14 Benedikt Ritter
>
>>
>>
>>
>> 2013/10/14 Matt Benson
>>
>>> Hi Benedikt, see inline:
>>>
>>>
>>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>>>
>>> > Author: britter
>>> > Date: Mon Oct 14 18:15:39 2013
>>> > New Revision: 1532011
>>> >
>>> > URL: http://svn.apache.org/r1532011
>>> > Log:
>>> > Deprecate methods that are available in Java 7's java.lang.Objects
>>> >
>>> > Modified:
>>> >
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>>> >
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>>> >
>>> > Modified:
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>>> > URL:
>>> >
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>>> >
>>> >
>>> ==
>>> > ---
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>>> > (original)
>>> > +++
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>>> > Mon Oct 14 18:15:39 2013
>>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
>>> > * @param array1 the left hand array to compare, may be {@code
>>> null}
>>> > * @param array2 the right hand array to compare, may be {@code
>>> null}
>>> > * @return {@code true} if the arrays are equal
>>> > + * @deprecated this method has been replaced by {@code
>>> > java.util.Objects.deepEquals(Object, Object)} and will be
>>> > + * removed from future releases.
>>> > */
>>> > public static boolean isEquals(final Object array1, final Object
>>> > array2) {
>>> > return new EqualsBuilder().append(array1, array2).isEquals();
>>> >
>>> > Modified:
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>>> > URL:
>>> >
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>>> >
>>> >
>>> ==
>>> > ---
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>>> > (original)
>>> > +++
>>> >
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>>> > Mon Oct 14 18:15:39 2013
>>> > @@ -149,6 +149,8 @@ public class ObjectUtils {
>>> > * @param object1 the first object, may be {@code null}
>>> > * @param object2 the second object, may be {@code null}
>>> > * @return {@code true} if the values of both objects are the same
>>> > + * @deprecated this method has been replaces by {@code
>>> > java.util.Objects.equals(Object, Object)} in Java 7 and will
>>> > + * be removed from future releases.
>>> > */
>>> > public static boolean equals(final Object object1, final Object
>>> > object2) {
>>> > if (object1 == object2) {
>>> > @@ -195,6 +197,8 @@ public class ObjectUtils {
>>> > * @param obj the object to obtain the hash code of, may be {@code
>>> > null}
>>> > * @return the hash code of the object, or zero if null
>>> > * @since 2.1
>>> > + * @deprecated this method has been replaced by {@code
>>> > java.util.Objects.hashCode(Object)} in Java 7 and will be
>>> > + * removed in future releases
>>> > */
>>> > public static int hashCode(final Object obj) {
>>> > // hashCode(Object) retained for performance, as hash code is
>>> > often critical
>>> > @@ -220,6 +224,8 @@ public class ObjectUtils {
>>> > * @param objects the objects to obtain the hash code of, may be
>>> > {@code null}
>>> > * @return the hash code of the objects, or zero if null
>>> > * @since 3.0
>>> > + * @deprecated this method has been replaced by {@code
>>> > java.util.Objects.hash(Object...)} in Java 7 an will be
>>> > + * removed in future releases.
>>> > */
>>> > public static int hashCodeMulti(final Object... objects) {
>>> >
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Hi Matt,
(fired the last one without adding my comment :-)
2013/10/14 Benedikt Ritter
>
>
>
> 2013/10/14 Matt Benson
>
>> Hi Benedikt, see inline:
>>
>>
>> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>>
>> > Author: britter
>> > Date: Mon Oct 14 18:15:39 2013
>> > New Revision: 1532011
>> >
>> > URL: http://svn.apache.org/r1532011
>> > Log:
>> > Deprecate methods that are available in Java 7's java.lang.Objects
>> >
>> > Modified:
>> >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> >
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>> >
>> > Modified:
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>> >
>> >
>> ==
>> > ---
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > (original)
>> > +++
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>> > Mon Oct 14 18:15:39 2013
>> > @@ -199,6 +199,8 @@ public class ArrayUtils {
>> > * @param array1 the left hand array to compare, may be {@code
>> null}
>> > * @param array2 the right hand array to compare, may be {@code
>> null}
>> > * @return {@code true} if the arrays are equal
>> > + * @deprecated this method has been replaced by {@code
>> > java.util.Objects.deepEquals(Object, Object)} and will be
>> > + * removed from future releases.
>> > */
>> > public static boolean isEquals(final Object array1, final Object
>> > array2) {
>> > return new EqualsBuilder().append(array1, array2).isEquals();
>> >
>> > Modified:
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>> >
>> >
>> ==
>> > ---
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>> > (original)
>> > +++
>> >
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>> > Mon Oct 14 18:15:39 2013
>> > @@ -149,6 +149,8 @@ public class ObjectUtils {
>> > * @param object1 the first object, may be {@code null}
>> > * @param object2 the second object, may be {@code null}
>> > * @return {@code true} if the values of both objects are the same
>> > + * @deprecated this method has been replaces by {@code
>> > java.util.Objects.equals(Object, Object)} in Java 7 and will
>> > + * be removed from future releases.
>> > */
>> > public static boolean equals(final Object object1, final Object
>> > object2) {
>> > if (object1 == object2) {
>> > @@ -195,6 +197,8 @@ public class ObjectUtils {
>> > * @param obj the object to obtain the hash code of, may be {@code
>> > null}
>> > * @return the hash code of the object, or zero if null
>> > * @since 2.1
>> > + * @deprecated this method has been replaced by {@code
>> > java.util.Objects.hashCode(Object)} in Java 7 and will be
>> > + * removed in future releases
>> > */
>> > public static int hashCode(final Object obj) {
>> > // hashCode(Object) retained for performance, as hash code is
>> > often critical
>> > @@ -220,6 +224,8 @@ public class ObjectUtils {
>> > * @param objects the objects to obtain the hash code of, may be
>> > {@code null}
>> > * @return the hash code of the objects, or zero if null
>> > * @since 3.0
>> > + * @deprecated this method has been replaced by {@code
>> > java.util.Objects.hash(Object...)} in Java 7 an will be
>> > + * removed in future releases.
>> > */
>> > public static int hashCodeMulti(final Object... objects) {
>> > int hash = 1;
>> > @@ -373,6 +379,9 @@ public class ObjectUtils {
>> > * @param obj the Object to {@code toString}, may be null
>> > * @return the passed in Object's toString, or {@code ""} if {@code
>> > null} input
>> > * @since 2.0
>> > + * @deprecated this method has been replaces by {@code
>> > java.util.Objects.toString(Object)} in Java 7 and will be
>> > + * removed in future releases. Note however that said method will
>> > return "null" for null references, while this
>> > + * method returns and empty String. To preserve behavior use {@code
>> > java.util.Objects.toString(myObject, "")}
>> >
>>
>> My preference here would be to begin providing
>> ObjectUtils#defaultString(Object) with the existing "", intended to
>> survive
>> beyond the removal of ObjectUtils.toString(). This will:
>> * preserve the users
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
2013/10/14 Matt Benson
> Hi Benedikt, see inline:
>
>
> On Mon, Oct 14, 2013 at 1:15 PM, wrote:
>
> > Author: britter
> > Date: Mon Oct 14 18:15:39 2013
> > New Revision: 1532011
> >
> > URL: http://svn.apache.org/r1532011
> > Log:
> > Deprecate methods that are available in Java 7's java.lang.Objects
> >
> > Modified:
> >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> >
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> >
> > Modified:
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > (original)
> > +++
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> > Mon Oct 14 18:15:39 2013
> > @@ -199,6 +199,8 @@ public class ArrayUtils {
> > * @param array1 the left hand array to compare, may be {@code
> null}
> > * @param array2 the right hand array to compare, may be {@code
> null}
> > * @return {@code true} if the arrays are equal
> > + * @deprecated this method has been replaced by {@code
> > java.util.Objects.deepEquals(Object, Object)} and will be
> > + * removed from future releases.
> > */
> > public static boolean isEquals(final Object array1, final Object
> > array2) {
> > return new EqualsBuilder().append(array1, array2).isEquals();
> >
> > Modified:
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > (original)
> > +++
> >
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> > Mon Oct 14 18:15:39 2013
> > @@ -149,6 +149,8 @@ public class ObjectUtils {
> > * @param object1 the first object, may be {@code null}
> > * @param object2 the second object, may be {@code null}
> > * @return {@code true} if the values of both objects are the same
> > + * @deprecated this method has been replaces by {@code
> > java.util.Objects.equals(Object, Object)} in Java 7 and will
> > + * be removed from future releases.
> > */
> > public static boolean equals(final Object object1, final Object
> > object2) {
> > if (object1 == object2) {
> > @@ -195,6 +197,8 @@ public class ObjectUtils {
> > * @param obj the object to obtain the hash code of, may be {@code
> > null}
> > * @return the hash code of the object, or zero if null
> > * @since 2.1
> > + * @deprecated this method has been replaced by {@code
> > java.util.Objects.hashCode(Object)} in Java 7 and will be
> > + * removed in future releases
> > */
> > public static int hashCode(final Object obj) {
> > // hashCode(Object) retained for performance, as hash code is
> > often critical
> > @@ -220,6 +224,8 @@ public class ObjectUtils {
> > * @param objects the objects to obtain the hash code of, may be
> > {@code null}
> > * @return the hash code of the objects, or zero if null
> > * @since 3.0
> > + * @deprecated this method has been replaced by {@code
> > java.util.Objects.hash(Object...)} in Java 7 an will be
> > + * removed in future releases.
> > */
> > public static int hashCodeMulti(final Object... objects) {
> > int hash = 1;
> > @@ -373,6 +379,9 @@ public class ObjectUtils {
> > * @param obj the Object to {@code toString}, may be null
> > * @return the passed in Object's toString, or {@code ""} if {@code
> > null} input
> > * @since 2.0
> > + * @deprecated this method has been replaces by {@code
> > java.util.Objects.toString(Object)} in Java 7 and will be
> > + * removed in future releases. Note however that said method will
> > return "null" for null references, while this
> > + * method returns and empty String. To preserve behavior use {@code
> > java.util.Objects.toString(myObject, "")}
> >
>
> My preference here would be to begin providing
> ObjectUtils#defaultString(Object) with the existing "", intended to survive
> beyond the removal of ObjectUtils.toString(). This will:
> * preserve the users' ability to call a method that implicitly uses ""
> * reduce confusion with Objects.toString(), and
> * enforce mnemonic retention by using the same terminology/behavior as
> StringUtils#defaultString()
>
> I'd welcome a
Re: svn commit: r1532011 - in /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3: ArrayUtils.java ObjectUtils.java
Hi Benedikt, see inline:
On Mon, Oct 14, 2013 at 1:15 PM, wrote:
> Author: britter
> Date: Mon Oct 14 18:15:39 2013
> New Revision: 1532011
>
> URL: http://svn.apache.org/r1532011
> Log:
> Deprecate methods that are available in Java 7's java.lang.Objects
>
> Modified:
>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
>
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
>
> Modified:
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>
> ==
> ---
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> (original)
> +++
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
> Mon Oct 14 18:15:39 2013
> @@ -199,6 +199,8 @@ public class ArrayUtils {
> * @param array1 the left hand array to compare, may be {@code null}
> * @param array2 the right hand array to compare, may be {@code null}
> * @return {@code true} if the arrays are equal
> + * @deprecated this method has been replaced by {@code
> java.util.Objects.deepEquals(Object, Object)} and will be
> + * removed from future releases.
> */
> public static boolean isEquals(final Object array1, final Object
> array2) {
> return new EqualsBuilder().append(array1, array2).isEquals();
>
> Modified:
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java?rev=1532011&r1=1532010&r2=1532011&view=diff
>
> ==
> ---
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> (original)
> +++
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
> Mon Oct 14 18:15:39 2013
> @@ -149,6 +149,8 @@ public class ObjectUtils {
> * @param object1 the first object, may be {@code null}
> * @param object2 the second object, may be {@code null}
> * @return {@code true} if the values of both objects are the same
> + * @deprecated this method has been replaces by {@code
> java.util.Objects.equals(Object, Object)} in Java 7 and will
> + * be removed from future releases.
> */
> public static boolean equals(final Object object1, final Object
> object2) {
> if (object1 == object2) {
> @@ -195,6 +197,8 @@ public class ObjectUtils {
> * @param obj the object to obtain the hash code of, may be {@code
> null}
> * @return the hash code of the object, or zero if null
> * @since 2.1
> + * @deprecated this method has been replaced by {@code
> java.util.Objects.hashCode(Object)} in Java 7 and will be
> + * removed in future releases
> */
> public static int hashCode(final Object obj) {
> // hashCode(Object) retained for performance, as hash code is
> often critical
> @@ -220,6 +224,8 @@ public class ObjectUtils {
> * @param objects the objects to obtain the hash code of, may be
> {@code null}
> * @return the hash code of the objects, or zero if null
> * @since 3.0
> + * @deprecated this method has been replaced by {@code
> java.util.Objects.hash(Object...)} in Java 7 an will be
> + * removed in future releases.
> */
> public static int hashCodeMulti(final Object... objects) {
> int hash = 1;
> @@ -373,6 +379,9 @@ public class ObjectUtils {
> * @param obj the Object to {@code toString}, may be null
> * @return the passed in Object's toString, or {@code ""} if {@code
> null} input
> * @since 2.0
> + * @deprecated this method has been replaces by {@code
> java.util.Objects.toString(Object)} in Java 7 and will be
> + * removed in future releases. Note however that said method will
> return "null" for null references, while this
> + * method returns and empty String. To preserve behavior use {@code
> java.util.Objects.toString(myObject, "")}
>
My preference here would be to begin providing
ObjectUtils#defaultString(Object) with the existing "", intended to survive
beyond the removal of ObjectUtils.toString(). This will:
* preserve the users' ability to call a method that implicitly uses ""
* reduce confusion with Objects.toString(), and
* enforce mnemonic retention by using the same terminology/behavior as
StringUtils#defaultString()
I'd welcome assenting or dissenting opinions here from other committers and
users.
Matt
> */
> public static String toString(final Object obj) {
> return obj == null ? "" : obj.toString();
> @@ -396,6 +405,8 @@ public class ObjectUtils {
> * @param nullS
