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