JEP 269: Convenience Factory Methods for Collections

[Stuart Marks]

On 9/29/15 11:32 PM, Stephen Colebourne wrote:
> In my view, the proposal is pretty good. I too use Guava's immutable
> classes as types, because of the extra value obtained. But that does
> not mean these methods should not be in the JDK. (Not every project
> uses Guava).

Hi Stephen,

Thanks for looking at the proposal. I'm glad you like it.

> I'd argue for two changes to the JEP.
>
> Map.fromEntries() -> Map.ofEntries()
> In JSR-310, we reserve "from" for factories with a high chance of
> failure due to performing some kind of conversion, and use "of" for
> factories that only fail if doing something stupid. It also means that
> IDE users will easily see both choices when auto-completing, thus
> easily learn how to go beyond the hard coded 6 entry factory.

Ah, this is quite helpful. I was mostly focusing on the "shape" of the 
many-entries Map factory (varargs, builder, etc.) that I didn't think too much 
about the name. I'll adopt your suggest of ofEntries().

> Map.Entry.entry() -> Map.entry()
> This would allow static imports to be focussed just on Map, and not
> needing Map.Entry as well (helpful in Eclipse at least). If the method
> were on Map.Entry, I'd expect it to be of(), whereas on Map itself,
> entry() is a good name. There might be a case for having both
> Map.entry() and Map.Entry.of().

Good. My current prototype already has the entry() convenience method on Map, 
not Map.Entry. (I'm not sure, but earlier prototypes might have had it on 
Map.Entry.)

My rationale for having the entry() method on Map is that it actually returns an 
instance of Map.KeyValueHolder, a concrete implementation Map.Entry that's 
intended to become a value class. The other obvious candidate implementation to 
return is AbstractMap.SimpleImmutableEntry, which is problematic to turn into a 
value class, as it's subclassable, has public constructors, and is serializable.

Soon, I'll post a webrev/specdiff/javadoc of the prototype so we can discuss 
things more concretely.

s'marks

> Stephen
>
>
>
> On 30 September 2015 at 03:35, Stuart Marks <stuart.marks at oracle.com> wrote:
>> 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
>>