JEP 269: Convenience Factory Methods for Collections
Stuart Marks
stuart.marks at oracle.com
Wed Sep 30 02:35:46 UTC 2015
Hi all, I've been on vacation for a few days. Did anything happen while I was
away? :-)
I see this JEP was posted as a Candidate, and Kevin and Remi had some comments.
I'll reply to Kevin's comments here and to Remi's separately.
Kevin,
I'm glad you don't think the proposal is bad. :-)
I definitely see the value in having immutability in the type system. If your
application is using Guava's immutable types, then it would certainly be a step
backwards to stop using them in favor of the factories proposed here.
However, I don't see this JEP as being in opposition to immutable collection
types. This JEP isn't specifically about immutable collections; it's about
convenience APIs (some of which create collection instances that happen to be
immutable). Immutable collection types could be added later without too much
difficulty. I'd be interested in seeing and even possibly working on such a
proposal in the future.
> 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.
Interesting. Given that Guava's Maps disallow null values, do you see a lot of
use of Optional for Map values in Guava? For the JDK, do you think it would be
preferable to allow null values in Maps, or to make Optional serializable? (Note
to readers: Guava's Optional is serializable but the JDK's is not.) Or is this
one of those problems where all the solutions suck?
> 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.
I'm not sure if one is allowed to say "evil" in a JEP, but I agree that the
"double brace" "idiom" is definitely evil! I did mention the potential for
memory leaks in the JEP, but you have a good point about serialization, not only
of the enclosing instance, but also of all captured references.
s'marks
More information about the core-libs-dev
mailing list