Objects.firstNonNull() Var Args

[gissuebot]

Original issue created by hoodwgs on 2010-07-20 at 07:31 PM

---

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 )

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-20 at 08:33 PM

---

You can use:

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

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

---

Status: WontFix

[gissuebot]

Original comment posted by kevinb@google.com on 2011-01-19 at 06:07 PM

---

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.

[gissuebot]

Original comment posted by amertum on 2011-01-19 at 08:23 PM

---

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

[gissuebot]

Original comment posted by morten.hattesen on 2011-02-10 at 12:28 AM

---

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.

[gissuebot]

Original comment posted by kurt.kluever on 2011-03-22 at 03:42 PM

---

Issue #577 has been merged into this issue.

[gissuebot]

Original comment posted by cgdecker on 2011-05-24 at 02:04 PM

---

Issue #632 has been merged into this issue.

[gissuebot]

Original comment posted by kak@google.com on 2013-02-26 at 08:16 PM

---

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)

---

Status: Research
Owner: kak@google.com
Labels: Type-Enhancement, Package-Base

[gissuebot]

Original comment posted by kevinb@google.com on 2013-04-30 at 05:24 PM

---

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

[gissuebot]

Original comment posted by aheydon@google.com on 2013-04-30 at 05:39 PM

---

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?

[gissuebot]

Original comment posted by asafr@google.com on 2013-04-30 at 08:02 PM

---

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

[gissuebot]

Original comment posted by amertum on 2013-04-30 at 10:34 PM

---

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