I am guessing methods such as StringUtils.trim() are included? If so, I
would like to say that a lot of times we use the StringUtils version
over the native String version because the StringUtils one is null-safe.
So taking these out would probably hurt users, at least until
null-safety (or NoneType or whatever) is built into the JDK.
-sujit
On Thu, 2009-04-09 at 06:43 -0400, James Carman wrote:
> On Thu, Apr 9, 2009 at 4:43 AM, Henri Yandell <flame...@gmail.com> wrote:
> > Is the following worth keeping in Lang?
> >
> > public Foo someJdkMethod(Object input) {
> > if(input == null) {
> > handleAccordingly();
> > }
> > return input.jdkMethod();
> > }
> >
> > I feel that we've bloated up with these methods, and is it really
> > worth it? I still have lots of if(x != null && x.callFoo()) type
> > invocations, having a small handful of methods available in Lang to
> > let me say if(FooUtils.callFoo(x)) isn't enough to hide all of the
> > other times when I might have to worry about it.
> >
> > Personally I'd like to see these methods removed from Lang [especially
> > given Stephen's blogging about null protected setting in some future
> > JVM].
> >
> > An example:
> >
> > public static String trim(String str) {
> > return str == null ? null : str.trim();
> > }
> >
> > Given that I'm likely to do N things to the string, chances are I'll
> > check for null up front and then invoke methods rather than repeatedly
> > writing ugly code by using StringUtils.
> >
> > Any thoughts in favour of these methods?
>
> What do bug catchers such as FindBugs do with situations like these?
> Would they still report it as a potential bug? Or, do they dig into
> the FooUtils.callFoo() methods to see if they're doing the null check?
> I'm just curious, I guess. If FindBugs is still going to report it
> as a potential bug, then it would seem like folks would probably be
> doing the null check on their own to quiet down FindBugs (not that
> everyone uses it of course).
>
> ---------------------------------------------------------------------
> 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
