JEP 269: Convenience Factory Methods for Collections

[Rémi Forax]

The current guideline seems to be that new collections introduced after Java 4 should not allow null.
ArrayDeque is an example of such collections.

This proposal introduces new static methods on both interfaces and implementations.
Interface static methods use new immutable collections, if those doesn't support null, a user can easily switch to the static method on one of the corresponding implementation class. By example, instead of using List.of (null), one can use ArrayList.of (null).
That's why i think it's fine to not allow null in new immutable collections.

regards,
Rémi 





Le 7 octobre 2015 02:13:30 CEST, Stuart Marks <stuart.marks at oracle.com> a écrit :
>
>
>On 10/3/15 7:16 AM, forax at univ-mlv.fr wrote:
>> "Kevin Bourrillion" <kevinb at google.com> wrote:
>>> We have ~1800 occurrences of Optional-valued Maps or Caches in
>Google. They
>>> do this for an actual reason: a negative result is meaningfully
>different
>>> from no result. This is addressed in our Optional javadoc .
>>
>> mapped-to-absent means that you know the keys you are waiting for, so
>you can store them in an external set (list, etc) and enjoy
>implementations like EnumMap or the couple JSObject/HiddenClass you
>found in most javascript engines.
>> Using Optional for that seem inefficient.
>
>Indeed, the Optional docs that Kevin linked to themselves have links to
>other 
>pages that describe techniques for avoiding use of nulls and Optionals
>in cases 
>such as this. Nonetheless, as Kevin points out, there are 1,800 such
>usages in 
>Google's code base.
>
>And personally, as a matter of style, I dislike using Optional in
>collections.
>
>My question is, is this enough of a problem that we should allow nulls
>in these 
>collections? I would prefer not to do this, but if there is evidence
>that this 
>would be a mistake, I'd like to hear it.
>
>And if disallowing nulls will cause developers to create things like 
>Map<K,Optional<V>>, are we ok with that, and are developers ok with
>that?
>
>s'marks