On 21 October 2013 11:52, Benedikt Ritter <benerit...@gmail.com> wrote: > > > Send from my mobile device > >> Am 21.10.2013 um 03:46 schrieb sebb <seb...@gmail.com>: >> >>> On 20 October 2013 15:03, Benedikt Ritter <brit...@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. >> >>> Thanks for adding the suppressions, btw :-) >>> >>> Benedikt >>> >>> >>> 2013/10/19 Henri Yandell <flame...@gmail.com> >>> >>>> 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 <gudnabr...@gmail.com> wrote: >>>>> >>>>> Perhaps we need some other kind of pre-deprecation convention. >>>>> >>>>> Matt >>>>> >>>>> >>>>>> On Fri, Oct 18, 2013 at 11:14 AM, sebb <seb...@gmail.com> 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 <brit...@apache.org> wrote: >>>>>>> Hi Matt, >>>>>>> >>>>>>> (fired the last one without adding my comment :-) >>>>>>> >>>>>>> >>>>>>> 2013/10/14 Benedikt Ritter <benerit...@gmail.com> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2013/10/14 Matt Benson <gudnabr...@gmail.com> >>>>>>>> >>>>>>>>> Hi Benedikt, see inline: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mon, Oct 14, 2013 at 1:15 PM, <brit...@apache.org> 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. >>>>>>> Makes sense to me. So if nobody objects, feel free to change it like >>>>>> that. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> >>>>>>>>>> */ >>>>>>>>>> public static String toString(final Object obj) { >>>>>>>>>> return obj == null ? "" : obj.toString(); >>>>>>>>>> @@ -396,6 +405,8 @@ public class ObjectUtils { >>>>>>>>>> * @param nullStr the String to return if {@code null} >>>> input, >>>>>> may >>>>>>>>> be >>>>>>>>>> null >>>>>>>>>> * @return the passed in Object's toString, or {@code >>>> nullStr} >>>>>> if >>>>>>>>>> {@code null} input >>>>>>>>>> * @since 2.0 >>>>>>>>>> + * @deprecated this method has been replaces by {@code >>>>>>>>>> java.util.Objects.toString(Object, String)} in Java 7 and >>>>>>>>>> + * will be removed in future releases. >>>>>>>>>> */ >>>>>>>>>> public static String toString(final Object obj, final String >>>>>>>>> nullStr) >>>>>>>>>> { >>>>>>>>>> return obj == null ? nullStr : obj.toString(); >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> http://people.apache.org/~britter/ >>>>>>> http://www.systemoutprintln.de/ >>>>>>> http://twitter.com/BenediktRitter >>>>>>> http://github.com/britter >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
