JEP 269: Convenience Factory Methods for Collections

[Kevin Bourrillion]

I don't think the proposal is bad, but for whatever it's worth to you... we
wouldn't use it. And would probably advise all Guava users not to, either.
In most cases new JDK functionality that replaces old Guava functionality
comes out anywhere from "slightly" to "a lot" better, and in all these
cases we advise switching to your stuff. But not this time, for at least
one key reason.

Guava's immutable collections are very useful as *types*, not just as
implementations. That is, while specific implementation classes are not
exposed, abstract types like ImmutableList and ImmutableSortedSet are
public (these should be thought of as "interfaces" in every logical sense
except that they cannot be implemented outside the package).

When advising how to chose, say, a method return type, our advice is "use
the most general type that still carries all the relevant semantic
guarantees your caller should be able to depend on." The additional
semantic information carried by our ImmutableSet type is that it (a) is a
thread-safe immutable snapshot, (b) will never contain null, and (c)
iterates in a deterministic order. Almost always, users do consider those
semantic guarantees to be highly relevant. If the method could not return
ImmutableSet, they would have to stuff a whole bunch of loose verbiage into
their javadoc about it (which is effectively nearly equivalent to that
information being lost).

Another example of the usefulness of types is that by making a field of
type ImmutableMap, then if my constructor accepts a plain Map I *can't
accidentally forget* to make a defensive copy. Another example is that if
anyone does try to call .add(), we can issue an IDE warning.

We could have a debate over just *how* important this is (we've become
solidly convinced over the years), but then, I'm not sure we see what the
upside of using this (for anyone able to use Guava) would be anyway.

(If, and somehow I feel this is unlikely, you were willing to add this
fleet of immutable types as abstract classes, you could go with a more
streamlined name than ours, like ImList. People would get used to it.)

Other quick comments:

Note that without permitting nulls, Map.of(key, Optional.of(value)) will
become reasonably common, and that fact you can't serialize that will
become even more strange than it already is.

I think the example of "double-brace initialization" should be even more
clearly labeled as pure evil. :-) You could also mention all the horrible
consequences if anyone ever serializes such a collection.



On Wed, Sep 23, 2015 at 5:02 PM, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/269
>
> - Mark
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com