Re: [LANG] Towards 3.2 and beyond

2013-10-15 Thread Gary Gregory
On Tue, Oct 15, 2013 at 8:49 AM, Gary Gregory wrote: > On Mon, Oct 14, 2013 at 2:24 PM, Benedikt Ritter 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 "

Re: [LANG] Towards 3.2 and beyond

2013-10-15 Thread Gary Gregory
On Mon, Oct 14, 2013 at 2:24 PM, Benedikt Ritter 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...)

Re: [LANG] Towards 3.2 and beyond

2013-10-14 Thread Henri Yandell
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, Oc

Re: [LANG] Towards 3.2 and beyond

2013-10-14 Thread Benedikt Ritter
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 requir

Re: [LANG] Towards 3.2 and beyond

2013-10-13 Thread Henri Yandell
Website fixed :) On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell 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 k

Re: [LANG] Towards 3.2 and beyond

2013-10-12 Thread Henri Yandell
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 c

Re: [LANG] Towards 3.2 and beyond

2013-10-12 Thread Henri Yandell
+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 Jav

Re: [LANG] Towards 3.2 and beyond

2013-10-12 Thread Gary Gregory
On Oct 12, 2013, at 6:13, 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 ha

Re: [LANG] Towards 3.2 and beyond

2013-10-12 Thread James Carman
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

[LANG] Towards 3.2 and beyond

2013-10-12 Thread Benedikt Ritter
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 exam