null-safe isEmpty for Iterables

[alibkord]

Is there a reason that the Iterables.isEmpty() is not null-safe (i.e.
it does not check for input being null)?

[Kevin Bourrillion]

The practice of interpreting a null collection to mean the same thing as an empty collection was thoroughly debunked years ago.  There is no good reason to do it.  If you're stuck with a bad API that returns null-meaning-empty to you, and you can't fix that API, you should deal with that problem as close to the source as possible:

    Set<Foo> foos = SillyClass.getFoos();

    if (foos == null) {

      foos = ImmutableSet.of();

    }

or:

    Set<Foo> foos = Objects.firstNonNull(

        SillyClass.getFoos(), ImmutableSet.<Foo>of());

On Sun, Jan 16, 2011 at 10:40 PM, alibkord <ali.ba...@gmail.com> wrote:

Is there a reason that the Iterables.isEmpty() is not null-safe (i.e.
it does not check for input being null)?

--
guava-...@googlegroups.com
http://guava-libraries.googlecode.com
http://groups.google.com/group/guava-discuss
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

--
Kevin Bourrillion @ Google
http://guava-libraries.googlecode.com

[alibkord]

I see your point.
Although, for example Spring framework's internal CollectionUtils
still uses the 'old' is-null-or-empty logic. i think it just saves you
an ugly null check every time, plus 99% of time (if not always) null
Collection semantically means the same as empty Collection (means no
data) in your business logic.
but hey, it's your project at the end of the day ;-)

Thanks.

A.

On Jan 18, 5:49 am, Kevin Bourrillion <kev...@google.com> wrote:
> The practice of interpreting a null collection to mean the same thing as an
> empty collection was thoroughly debunked years ago.  There is no good reason
> to do it.  If you're stuck with a bad API that returns null-meaning-empty to
> you, and you can't fix that API, you should deal with that problem as close
> to the source as possible:
>
>     Set<Foo> foos = SillyClass.getFoos();
>     if (foos == null) {
>       foos = ImmutableSet.of();
>     }
>
> or:
>
>     Set<Foo> foos = Objects.firstNonNull(
>         SillyClass.getFoos(), ImmutableSet.<Foo>of());
>

> On Sun, Jan 16, 2011 at 10:40 PM, alibkord <ali.baghb...@gmail.com> wrote:
> > Is there a reason that the Iterables.isEmpty() is not null-safe (i.e.
> > it does not check for input being null)?
>
> > --
> > guava-...@googlegroups.com
> >http://guava-libraries.googlecode.com
> >http://groups.google.com/group/guava-discuss

> > unsubscribe: guava-discus...@googlegroups.com<guava-discuss%2Bunsu...@googlegroups.com>

[Dimitris Andreou]

On Mon, Jan 17, 2011 at 3:00 PM, alibkord <ali.ba...@gmail.com> wrote:

I see your point.
Although, for example Spring framework's internal CollectionUtils
still uses the 'old' is-null-or-empty logic. i think it just saves you
an ugly null check every time, plus 99% of time (if not always) null
Collection semantically means the same as empty Collection (means no
data) in your business logic. 

but hey, it's your project at the end of the day ;-)

Very generous of you to allow Kevin the luxury of having his opinion, even only because he happens to be the owner [insert lame internal joke here] of the code. I'm sure it is thoroughly appreciated.

PS: please post to stackoverflow questions like these. There are a ton of people who can provide answers there.

[Nathan Bryant]

So the problem with null-as-empty is in the worst case, every time you
want to iterate, you need to do:

if (xs != null)
for (Object x : xs)
..

This thing becomes like a virus: eventually, this is what your staff
will write, if they are faced with a lot of nulls meaning empty. Besides
adding an extra level of identation, which is problematic in and of
itself, this increases the McCabe complexity of just about every file in
your codebase, and hence, your test footprint. Had an employee that did
this. Made him go back and change it. Not Recommended.

[alibkord]

Oops! did I tresspass in the realm of the mighty genius @Google,
specially by commiting the deadly sin of bringing up the Spring
framework! Only to be punched in the face by whom seems to be the
bouncer in this joint (Dimitri, put your lame joke here if this is not
funny enough for you ;-)

FYI, we're replacing com.google... with org.springframework... in the
meanwhile, not that you care!

Have fun saving the world :-)

On Jan 18, 10:40 am, Dimitris Andreou <jim.andr...@gmail.com> wrote:

> > <guava-discuss%2Bunsu...@googlegroups.com<guava-discuss%252Buns...@googlegroups.com>

[Johan Van den Neste]

All flamebait aside, +1 for applying Objects.firstNonNull at the
source to rid your code of null pointers.

I passionately hate null checks. Having once waded for days through
someone else's (extremely) null-check-bloated code, I am forever
traumatized.

--
Johan Van den Neste

[Nikolas Everett]

On Tue, Jan 18, 2011 at 4:49 AM, Johan Van den Neste <jvdn...@gmail.com> wrote:

All flamebait aside, +1 for applying Objects.firstNonNull at the
source to rid your code of null pointers.

+1 here too.  Wrap the whole thing up.

Nik 

[morten hattesen]

Another reason NOT to make "null" synonymous with "empty collection":
You would have to implement equals(Object) and hashCode() on the
containing class to make null and empty collection "equal", which is
non-trivial.

/Morten

On 18 Jan., 00:40, Dimitris Andreou <jim.andr...@gmail.com> wrote:

> > > > unsubscribe: guava-discus...@googlegroups.com<guava-discuss%2Bunsubscribe@goog legroups.com>
> > <guava-discuss%2Bunsu...@googlegroups.com<guava-discuss%252Bunsubscribe @googlegroups.com>

>
> > > > This list is for discussion; for help, post to Stack Overflow instead:
> > > >http://stackoverflow.com/questions/ask
> > > > Use the tag "guava".
>
> > > --
> > > Kevin Bourrillion @ Googlehttp://guava-libraries.googlecode.com
>
> > --
> > guava-...@googlegroups.com
> >http://guava-libraries.googlecode.com
> >http://groups.google.com/group/guava-discuss

> > unsubscribe: guava-discus...@googlegroups.com<guava-discuss%2Bunsubscribe@goog legroups.com>

[morten hattesen]

To further support the argument of NEVER using null as meaning
"empty":
It is virtually cost-less to return an immutable empty collection
using the java.util.Collections.emptyXxx() methods, which returns
empty immutable singletons and even does a good job of type inference.
And as indicated in previous posts: client code becomes less copmplex
and more readable.

Therefore Guava should NOT support this practice.

/Morten

> >>> unsubscribe: guava-discus...@googlegroups.com<guava-discuss%2Bunsubscribe@goog legroups.com>

[Brent Payne]

-1 for this. I agree, I treat them as independent values. null being
unknown and empty as known empty. I would suggest wrapping your calls
to APIs that return null as empty with custom code that returns an
empty list instead. This way you only need to place the null check in
one place and not littered throughout the code. But if you prefer the
null, you can wrap APIs that return empty lists with ones that return
null then place your if(var!=null) to your hearts desire. Got to go,
apparitions of C macros are starting to haunt me.

bp

[Kevin Bourrillion]

On Wed, Jan 19, 2011 at 10:16 AM, Brent Payne <brent...@gmail.com> wrote:

-1 for this. I agree, I treat them as independent values.  null being
unknown and empty as known empty.

Right; the reason to allow a collection reference to be null is because that carries some actual distinct meaning from an empty collection, such as "not applicable", "not yet initialized", or whatever (and that distinction is important).  The need for that should pretty rare, though.