You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2013/10/12 12:13:19 UTC
[LANG] Towards 3.2 and beyond
Hi guys,
I'm currently cleaning up the current trunk of lang in preparation of a new
release (as always, any help is appreciated ;-).
Now I came across methods like ObjectUtils.hashCode(Object), which is
obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm sure
there are more examples. I'd like to mark methods that are obsolete
with Java 7 as deprecated, so that we can remove them with the next major
release (which should target Java 7, IMHO).
Thoughts? Objections? (and please no "why Java 7?" ;-)
Benedikt
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [LANG] Towards 3.2 and beyond
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 15, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Oct 14, 2013 at 2:24 PM, Benedikt Ritter <br...@apache.org> wrote:
>> Hey,
>>
>> please review http://svn.apache.org/r1532011
>>
>> I was thinking about deprecating Validate.notNull(T) as well because we now
>> have Objects.requireNotNull(Object). The "problem" is that Validate has
>> notNull(T, String, Object...) which does substitution in the message, while
>> Objects only has requireNotNull(Object, String). Deprecating only
>> Validate.notNull(T) would be strange, wouldn't it?
>
> I like our better because we give a message to the NPE which helps it
> distinguish with a null de-reference attempt.
>
> My beef is more that I feel like we got our Validate class wrong
> because we throw an NPE instead of an ISE.
Oops, I mean an IAE.
Gary
>
> Gary
>
>>
>> Benedikt
>>
>>
>> 2013/10/13 Henri Yandell <fl...@gmail.com>
>>
>>> Website fixed :)
>>>
>>>
>>> On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell <fl...@gmail.com>
>>> wrote:
>>>
>>> > I think this is the priority issue:
>>> >
>>> > https://issues.apache.org/jira/browse/LANG-894
>>> >
>>> > If we can't fix and deploy our website, having new code is largely
>>> > pointless :)
>>> >
>>> > I'm guessing we're on some new (yeah I know, probably old by now) site
>>> > here and clean up still needs doing. Presumably for most components if
>>> Lang
>>> > hasn't been fixed.
>>> >
>>> > Hen
>>> >
>>> >
>>> > On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <flamefew@gmail.com
>>> >wrote:
>>> >
>>> >> +1 to Java 7, though if that only means a few methods should be removed
>>> >> I'd go with deprecating with a note they'll be removed in Lang 4.0.
>>> >>
>>> >> We should deprecate the time package warning that it will be replaced
>>> >> with a new package based on Java 8's new API in Lang 4.0 :) I'm assuming
>>> >> 4.0 will be Java 8 focused.
>>> >>
>>> >> Hen
>>> >>
>>> >>
>>> >> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <garydgregory@gmail.com
>>> >wrote:
>>> >>
>>> >>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
>>> >>>
>>> >>> > Hi guys,
>>> >>> >
>>> >>> > I'm currently cleaning up the current trunk of lang in preparation of
>>> >>> a new
>>> >>> > release (as always, any help is appreciated ;-).
>>> >>> >
>>> >>> > Now I came across methods like ObjectUtils.hashCode(Object), which is
>>> >>> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm
>>> >>> sure
>>> >>> > there are more examples. I'd like to mark methods that are obsolete
>>> >>> > with Java 7 as deprecated, so that we can remove them with the next
>>> >>> major
>>> >>> > release (which should target Java 7, IMHO).
>>> >>> >
>>> >>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
>>> >>>
>>> >>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
>>> >>> before deprecating. As James pointed out, we usually are null safe.
>>> >>> >
>>> >>> > Benedikt
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > http://people.apache.org/~britter/
>>> >>> > http://www.systemoutprintln.de/
>>> >>> > http://twitter.com/BenediktRitter
>>> >>> > http://github.com/britter
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Towards 3.2 and beyond
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Oct 14, 2013 at 2:24 PM, Benedikt Ritter <br...@apache.org> wrote:
> Hey,
>
> please review http://svn.apache.org/r1532011
>
> I was thinking about deprecating Validate.notNull(T) as well because we now
> have Objects.requireNotNull(Object). The "problem" is that Validate has
> notNull(T, String, Object...) which does substitution in the message, while
> Objects only has requireNotNull(Object, String). Deprecating only
> Validate.notNull(T) would be strange, wouldn't it?
I like our better because we give a message to the NPE which helps it
distinguish with a null de-reference attempt.
My beef is more that I feel like we got our Validate class wrong
because we throw an NPE instead of an ISE.
Gary
>
> Benedikt
>
>
> 2013/10/13 Henri Yandell <fl...@gmail.com>
>
>> Website fixed :)
>>
>>
>> On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell <fl...@gmail.com>
>> wrote:
>>
>> > I think this is the priority issue:
>> >
>> > https://issues.apache.org/jira/browse/LANG-894
>> >
>> > If we can't fix and deploy our website, having new code is largely
>> > pointless :)
>> >
>> > I'm guessing we're on some new (yeah I know, probably old by now) site
>> > here and clean up still needs doing. Presumably for most components if
>> Lang
>> > hasn't been fixed.
>> >
>> > Hen
>> >
>> >
>> > On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <flamefew@gmail.com
>> >wrote:
>> >
>> >> +1 to Java 7, though if that only means a few methods should be removed
>> >> I'd go with deprecating with a note they'll be removed in Lang 4.0.
>> >>
>> >> We should deprecate the time package warning that it will be replaced
>> >> with a new package based on Java 8's new API in Lang 4.0 :) I'm assuming
>> >> 4.0 will be Java 8 focused.
>> >>
>> >> Hen
>> >>
>> >>
>> >> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <garydgregory@gmail.com
>> >wrote:
>> >>
>> >>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
>> >>>
>> >>> > Hi guys,
>> >>> >
>> >>> > I'm currently cleaning up the current trunk of lang in preparation of
>> >>> a new
>> >>> > release (as always, any help is appreciated ;-).
>> >>> >
>> >>> > Now I came across methods like ObjectUtils.hashCode(Object), which is
>> >>> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm
>> >>> sure
>> >>> > there are more examples. I'd like to mark methods that are obsolete
>> >>> > with Java 7 as deprecated, so that we can remove them with the next
>> >>> major
>> >>> > release (which should target Java 7, IMHO).
>> >>> >
>> >>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
>> >>>
>> >>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
>> >>> before deprecating. As James pointed out, we usually are null safe.
>> >>> >
>> >>> > Benedikt
>> >>> >
>> >>> >
>> >>> > --
>> >>> > http://people.apache.org/~britter/
>> >>> > http://www.systemoutprintln.de/
>> >>> > http://twitter.com/BenediktRitter
>> >>> > http://github.com/britter
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Towards 3.2 and beyond
Posted by Henri Yandell <fl...@gmail.com>.
I agree it would be strange. I think we consider this as a duplication to
keep. Deprecating and removing one method out of Validate isn't going to
simplify its API, and I wouldn't expect users to be using it for only that
one method.
So -1 to deprecation of Validate.notNull(...).
Hen
On Mon, Oct 14, 2013 at 11:24 AM, Benedikt Ritter <br...@apache.org>wrote:
> Hey,
>
> please review http://svn.apache.org/r1532011
>
> I was thinking about deprecating Validate.notNull(T) as well because we now
> have Objects.requireNotNull(Object). The "problem" is that Validate has
> notNull(T, String, Object...) which does substitution in the message, while
> Objects only has requireNotNull(Object, String). Deprecating only
> Validate.notNull(T) would be strange, wouldn't it?
>
> Benedikt
>
>
> 2013/10/13 Henri Yandell <fl...@gmail.com>
>
> > Website fixed :)
> >
> >
> > On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell <fl...@gmail.com>
> > wrote:
> >
> > > I think this is the priority issue:
> > >
> > > https://issues.apache.org/jira/browse/LANG-894
> > >
> > > If we can't fix and deploy our website, having new code is largely
> > > pointless :)
> > >
> > > I'm guessing we're on some new (yeah I know, probably old by now) site
> > > here and clean up still needs doing. Presumably for most components if
> > Lang
> > > hasn't been fixed.
> > >
> > > Hen
> > >
> > >
> > > On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <flamefew@gmail.com
> > >wrote:
> > >
> > >> +1 to Java 7, though if that only means a few methods should be
> removed
> > >> I'd go with deprecating with a note they'll be removed in Lang 4.0.
> > >>
> > >> We should deprecate the time package warning that it will be replaced
> > >> with a new package based on Java 8's new API in Lang 4.0 :) I'm
> assuming
> > >> 4.0 will be Java 8 focused.
> > >>
> > >> Hen
> > >>
> > >>
> > >> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <garydgregory@gmail.com
> > >wrote:
> > >>
> > >>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org>
> wrote:
> > >>>
> > >>> > Hi guys,
> > >>> >
> > >>> > I'm currently cleaning up the current trunk of lang in preparation
> of
> > >>> a new
> > >>> > release (as always, any help is appreciated ;-).
> > >>> >
> > >>> > Now I came across methods like ObjectUtils.hashCode(Object), which
> is
> > >>> > obsolete in Java 7 since we have Objects.hashCode(Object) there.
> I'm
> > >>> sure
> > >>> > there are more examples. I'd like to mark methods that are obsolete
> > >>> > with Java 7 as deprecated, so that we can remove them with the next
> > >>> major
> > >>> > release (which should target Java 7, IMHO).
> > >>> >
> > >>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
> > >>>
> > >>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
> > >>> before deprecating. As James pointed out, we usually are null safe.
> > >>> >
> > >>> > Benedikt
> > >>> >
> > >>> >
> > >>> > --
> > >>> > http://people.apache.org/~britter/
> > >>> > http://www.systemoutprintln.de/
> > >>> > http://twitter.com/BenediktRitter
> > >>> > http://github.com/britter
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [LANG] Towards 3.2 and beyond
Posted by Benedikt Ritter <br...@apache.org>.
Hey,
please review http://svn.apache.org/r1532011
I was thinking about deprecating Validate.notNull(T) as well because we now
have Objects.requireNotNull(Object). The "problem" is that Validate has
notNull(T, String, Object...) which does substitution in the message, while
Objects only has requireNotNull(Object, String). Deprecating only
Validate.notNull(T) would be strange, wouldn't it?
Benedikt
2013/10/13 Henri Yandell <fl...@gmail.com>
> Website fixed :)
>
>
> On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell <fl...@gmail.com>
> wrote:
>
> > I think this is the priority issue:
> >
> > https://issues.apache.org/jira/browse/LANG-894
> >
> > If we can't fix and deploy our website, having new code is largely
> > pointless :)
> >
> > I'm guessing we're on some new (yeah I know, probably old by now) site
> > here and clean up still needs doing. Presumably for most components if
> Lang
> > hasn't been fixed.
> >
> > Hen
> >
> >
> > On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <flamefew@gmail.com
> >wrote:
> >
> >> +1 to Java 7, though if that only means a few methods should be removed
> >> I'd go with deprecating with a note they'll be removed in Lang 4.0.
> >>
> >> We should deprecate the time package warning that it will be replaced
> >> with a new package based on Java 8's new API in Lang 4.0 :) I'm assuming
> >> 4.0 will be Java 8 focused.
> >>
> >> Hen
> >>
> >>
> >> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >>
> >>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
> >>>
> >>> > Hi guys,
> >>> >
> >>> > I'm currently cleaning up the current trunk of lang in preparation of
> >>> a new
> >>> > release (as always, any help is appreciated ;-).
> >>> >
> >>> > Now I came across methods like ObjectUtils.hashCode(Object), which is
> >>> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm
> >>> sure
> >>> > there are more examples. I'd like to mark methods that are obsolete
> >>> > with Java 7 as deprecated, so that we can remove them with the next
> >>> major
> >>> > release (which should target Java 7, IMHO).
> >>> >
> >>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
> >>>
> >>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
> >>> before deprecating. As James pointed out, we usually are null safe.
> >>> >
> >>> > Benedikt
> >>> >
> >>> >
> >>> > --
> >>> > http://people.apache.org/~britter/
> >>> > http://www.systemoutprintln.de/
> >>> > http://twitter.com/BenediktRitter
> >>> > http://github.com/britter
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [LANG] Towards 3.2 and beyond
Posted by Henri Yandell <fl...@gmail.com>.
Website fixed :)
On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell <fl...@gmail.com> wrote:
> I think this is the priority issue:
>
> https://issues.apache.org/jira/browse/LANG-894
>
> If we can't fix and deploy our website, having new code is largely
> pointless :)
>
> I'm guessing we're on some new (yeah I know, probably old by now) site
> here and clean up still needs doing. Presumably for most components if Lang
> hasn't been fixed.
>
> Hen
>
>
> On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <fl...@gmail.com>wrote:
>
>> +1 to Java 7, though if that only means a few methods should be removed
>> I'd go with deprecating with a note they'll be removed in Lang 4.0.
>>
>> We should deprecate the time package warning that it will be replaced
>> with a new package based on Java 8's new API in Lang 4.0 :) I'm assuming
>> 4.0 will be Java 8 focused.
>>
>> Hen
>>
>>
>> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
>>>
>>> > Hi guys,
>>> >
>>> > I'm currently cleaning up the current trunk of lang in preparation of
>>> a new
>>> > release (as always, any help is appreciated ;-).
>>> >
>>> > Now I came across methods like ObjectUtils.hashCode(Object), which is
>>> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm
>>> sure
>>> > there are more examples. I'd like to mark methods that are obsolete
>>> > with Java 7 as deprecated, so that we can remove them with the next
>>> major
>>> > release (which should target Java 7, IMHO).
>>> >
>>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
>>>
>>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
>>> before deprecating. As James pointed out, we usually are null safe.
>>> >
>>> > Benedikt
>>> >
>>> >
>>> > --
>>> > http://people.apache.org/~britter/
>>> > http://www.systemoutprintln.de/
>>> > http://twitter.com/BenediktRitter
>>> > http://github.com/britter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
Re: [LANG] Towards 3.2 and beyond
Posted by Henri Yandell <fl...@gmail.com>.
I think this is the priority issue:
https://issues.apache.org/jira/browse/LANG-894
If we can't fix and deploy our website, having new code is largely
pointless :)
I'm guessing we're on some new (yeah I know, probably old by now) site here
and clean up still needs doing. Presumably for most components if Lang
hasn't been fixed.
Hen
On Sat, Oct 12, 2013 at 10:17 AM, Henri Yandell <fl...@gmail.com> wrote:
> +1 to Java 7, though if that only means a few methods should be removed
> I'd go with deprecating with a note they'll be removed in Lang 4.0.
>
> We should deprecate the time package warning that it will be replaced with
> a new package based on Java 8's new API in Lang 4.0 :) I'm assuming 4.0
> will be Java 8 focused.
>
> Hen
>
>
> On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <ga...@gmail.com>wrote:
>
>> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
>>
>> > Hi guys,
>> >
>> > I'm currently cleaning up the current trunk of lang in preparation of a
>> new
>> > release (as always, any help is appreciated ;-).
>> >
>> > Now I came across methods like ObjectUtils.hashCode(Object), which is
>> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm
>> sure
>> > there are more examples. I'd like to mark methods that are obsolete
>> > with Java 7 as deprecated, so that we can remove them with the next
>> major
>> > release (which should target Java 7, IMHO).
>> >
>> > Thoughts? Objections? (and please no "why Java 7?" ;-)
>>
>> Heston Java 7 :) Please make sure there is an exact equivalent in J7
>> before deprecating. As James pointed out, we usually are null safe.
>> >
>> > Benedikt
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
Re: [LANG] Towards 3.2 and beyond
Posted by Henri Yandell <fl...@gmail.com>.
+1 to Java 7, though if that only means a few methods should be removed I'd
go with deprecating with a note they'll be removed in Lang 4.0.
We should deprecate the time package warning that it will be replaced with
a new package based on Java 8's new API in Lang 4.0 :) I'm assuming 4.0
will be Java 8 focused.
Hen
On Sat, Oct 12, 2013 at 4:33 AM, Gary Gregory <ga...@gmail.com>wrote:
> On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
>
> > Hi guys,
> >
> > I'm currently cleaning up the current trunk of lang in preparation of a
> new
> > release (as always, any help is appreciated ;-).
> >
> > Now I came across methods like ObjectUtils.hashCode(Object), which is
> > obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm sure
> > there are more examples. I'd like to mark methods that are obsolete
> > with Java 7 as deprecated, so that we can remove them with the next major
> > release (which should target Java 7, IMHO).
> >
> > Thoughts? Objections? (and please no "why Java 7?" ;-)
>
> Heston Java 7 :) Please make sure there is an exact equivalent in J7
> before deprecating. As James pointed out, we usually are null safe.
> >
> > Benedikt
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [LANG] Towards 3.2 and beyond
Posted by Gary Gregory <ga...@gmail.com>.
On Oct 12, 2013, at 6:13, Benedikt Ritter <br...@apache.org> wrote:
> Hi guys,
>
> I'm currently cleaning up the current trunk of lang in preparation of a new
> release (as always, any help is appreciated ;-).
>
> Now I came across methods like ObjectUtils.hashCode(Object), which is
> obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm sure
> there are more examples. I'd like to mark methods that are obsolete
> with Java 7 as deprecated, so that we can remove them with the next major
> release (which should target Java 7, IMHO).
>
> Thoughts? Objections? (and please no "why Java 7?" ;-)
Heston Java 7 :) Please make sure there is an exact equivalent in J7
before deprecating. As James pointed out, we usually are null safe.
>
> Benedikt
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Towards 3.2 and beyond
Posted by James Carman <ja...@carmanconsulting.com>.
Sometimes our methods are null safe when they are not. Haven't looked into
this case yet, but just be sure to consider it when marking things as
obsolete.
On Saturday, October 12, 2013, Benedikt Ritter wrote:
> Hi guys,
>
> I'm currently cleaning up the current trunk of lang in preparation of a new
> release (as always, any help is appreciated ;-).
>
> Now I came across methods like ObjectUtils.hashCode(Object), which is
> obsolete in Java 7 since we have Objects.hashCode(Object) there. I'm sure
> there are more examples. I'd like to mark methods that are obsolete
> with Java 7 as deprecated, so that we can remove them with the next major
> release (which should target Java 7, IMHO).
>
> Thoughts? Objections? (and please no "why Java 7?" ;-)
>
> Benedikt
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>