Why do ImmutableList.of() and friends prohibit null elements?

Summary pretty much says it all. Here's the relevant snippet of code in ImmutableList.createFromIterable():

  if (element == null) {
    throw new NullPointerException("at index " + index);
  }

I've run into this several times and can't see why a general-purpose library function should impose this limitation.

Edit 1: by "gene开发者_如何学Cral-purpose", I'd be happy with 95% of cases. But I don't think I've written 100 calls to ImmutableList.of() yet, and have been bitten by this more than once. Maybe I'm an outlier, though. :)

Edit 2: I guess my big complaint is that this creates a "hiccup" when interacting with standard java.util collections. As you pointed out in your talk, problems with nulls in collections can show up far away from where those nulls were inserted. But if I have a long chain of code that puts nulls in a standard collection at one end and handles them properly at the other, then I'm unable to substitute a google collections class at any point along the way, because it'll immediately throw a NullPointerException.

---

I explained this at the 25-minute point of this video: https://youtu.be/ZeO_J2OcHYM?t=1495

Sorry for the lazy answer, but this is after all only a "why" question (arguably not appropriate to StackOverflow?).

EDIT: Here's another point I'm not sure I made clear in the video: the total (across all of the world's Java code), amount of extra code that has to be written for those null-friendly cases to use the old standbys Collections.unmodifiableList(Arrays.asList(...)) etc. is overwhelmed by the total (across all of the world's Java code) amount of extra checkArgument(!foos.contains(null)) calls everyone would need to add if our collections didn't take care of that for you. Most, by FAR, usages of a collection do not expect any nulls to be present, and really should fail fast if any are.

---

In general in Google Collections the developers are of the group that does not believe that nulls should be an expected general purpose parameter.

---

From Guava's Github Page

Careless use of null can cause a staggering variety of bugs. Studying the Google code base, we found that something like 95% of collections weren't supposed to have any null values in them, and having those fail fast rather than silently accept null would have been helpful to developers.

The Guava position is largely, that there are other ways to avoid nulls in collections. For example, fetching a batch of items with a specific key. E.g.

// If a widget for the given id does not exist, return `null` in the list
private List<Widget> getWidgets(List<String> widgetIds);

// Could be restructured to use a Map type like this and avoids nulls completely.

// If a widget for the given id does not exist, no entry in list
private Map<String, Widget> getWidgets(List<String> widgetIds);

---

One reason is that it allows functions that work on the list not to have to check every element for Null, significantly improving performance.