Objects.firstNonNull() Var Args

[GoogleCodeExporter]

It would be nice to have an varargs Objects.firstNonNull()
This would reduce a lot of "if"s "else"s.

Implementation:
    public static <T> T firstNonNull( T... objs ){
        for( T obj : objs )
            if( obj != null )
                return obj;
        throw new NullPointerException();
    }

Utilization:
    String var1 = null;
    String var2 = null;
    String var3 = "ccc";
    String var4 = "aaa";

    String aaa = Objects2.firstNonNull( var1,var2,var3,var4 );
    System.out.println( aaa );

Maybe we can put some similar methods on the GUAVA
like...
Iterable.firstNonNull( Iterable<T> col )

Original issue reported on code.google.com by hood...@gmail.com on 20 Jul 2010 at 7:31

[GoogleCodeExporter]

You can use:

Iterables.find(collection, Predicates.notNull()).

For varargs, use Arrays.asList(a, b, c, ...) as the 'collection' above.

Original comment by kevinb@google.com on 20 Jul 2010 at 8:33

• Changed state: WontFix

[GoogleCodeExporter]

Since this keeps coming up, here's my latest explanation of the rejection:

As noted, I feel the way to evaluate this method is not as a generalization of 
Objects.firstNonNull(a, b), but as a specialization of Iterables.find(), which 
differs from that method in two ways:

1. Uses a particular predicate (Predicates.notNull())
2. Has varargs

To point #1, the design focus of Guava has always been to provide generalized 
capabilities that can be easily composed together to get more specific results. 
 If we ever redundantly offer a function that is just a specialization of 
another, that is really only because that special case is very, very commonly 
used.

To point #2, I am very reluctant to add more any varargs methods to any of our 
libraries.  This language feature has not panned out very poorly.  It causes 
warnings, it forces arguments to the last position, it causes very confusing 
overload resolution ambiguities.... Plus, when Java gets collection literals 
(as slated, although I do understand it will be a while), that will be an 
alternative that doesn't suffer any of those drawbacks.  At that point the 
benefits of varargs will just completely evaporate into a savings of two 
characters ("[" and "]"), and we'll regret all the varargs methods we're stuck 
with.

So what about only adding a 3-argument form?  The question is how sharply the 
applicability of the method drops off between 2 and 3 and between 3 and 4.  I 
predict, without evidence, that the drop-off is very, very sharp from 2 to 3.  
The drop-off from 3 to 4 is probably not as high, relatively speaking, as the 
2->3, so I think we'd only be buying a bit of time until users say "hey, it 
makes no sense that you stop at 3, now how about 4, 5, ....."

In summary, the find(asList(), notNull()) alternative exists, and while it's 
certainly a little clumsy, I believe it's not too clumsy when we consider the 
relative rarity of the use case.

Original comment by kevinb@google.com on 19 Jan 2011 at 6:07

[GoogleCodeExporter]

My comment has really no added value on this topic but I'd like to tell that I 
really like the way you argue :D

Original comment by amer...@gmail.com on 19 Jan 2011 at 8:23

[GoogleCodeExporter]

I can clearly see the arguments for rejecting the overloaded 
Objects.firstNonNull(), but the suggested alternatives are no where near as 
declarative/expressive as...

String a = Objects.firstNonNull( var1, var2, var3, var4);

They all drown in boilerplate (Predicates, Iterables, asList, ...) and loose 
the clarity/expressiveness.

Original comment by morten.h...@gmail.com on 10 Feb 2011 at 12:28

[GoogleCodeExporter]

Issue 577 has been merged into this issue.

Original comment by kurt.kluever on 22 Mar 2011 at 3:42

[GoogleCodeExporter]

Issue 632 has been merged into this issue.

Original comment by cgdec...@gmail.com on 24 May 2011 at 2:04

[GoogleCodeExporter]

Let's move this into the research bucket. Both Greg and I were +1 on adding it. 
Kevin wanted us to try to decide what "N" to choose.

Semi-related (overloads w/o varargs):
 ImmutableList#of(e1, ... e11)
 ImmutableSet#of(e1, ... e5)
 ImmutableMap#of(k1, v1, ... k5, v5)

Original comment by kak@google.com on 26 Feb 2013 at 8:16

• Changed state: Research
• Added labels: Package-Base, Type-Enhancement

[GoogleCodeExporter]

Still, no one has once offered motivating use cases. These would make it clear 
to us why existing solutions are insufficient.

Original comment by kevinb@google.com on 30 Apr 2013 at 5:24

[GoogleCodeExporter]

I'd like to second Morten's comment #4 on this topic. When people are looking 
to find the first non-null element in a sequence of multiple values, their 
first thought is not to combine Iterables.find(), Arrays.asList(), and 
Predicates.notNull(). At the very least, could you at least augment the Javadoc 
of the existing Objects.firstNonNull() method to include the text of Kevin's 
comment #1?

Original comment by ahey...@google.com on 30 Apr 2013 at 5:39

[GoogleCodeExporter]

Why does the current firstNonNull have 2 parameters? Why not 3 or 5?
firstNonNull implies - by its name - that it's a way, even *the* way to get the 
first non null among objects. Kevin's #1 comment is just as well applied to 2 
params as to any longer list.

Thus, if having firstNonNull makes any sense, then have a vararg version of it 
makes sense. If for any >2 number of params the less expressive workaround 
suffices, then it suffices for =2 params and firstNonNull should be deprecated 
or removed.

So, please either prove me wrong, extend a vararg version, or remove the method.

Kindly (though firmly),
Asaf

Original comment by as...@google.com on 30 Apr 2013 at 8:02

[GoogleCodeExporter]

It makes me think that firstNonNull(var1, var2) is equivalent to 
Optional.fromNullable(var1).or(var2) as well.

Original comment by amer...@gmail.com on 30 Apr 2013 at 10:34

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:18

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit