please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

On 7/16/14 6:03 PM, Remi Forax wrote:
> On 07/17/2014 02:46 AM, Stuart Marks wrote:
>> Please review this draft JEP for Convenience Factory Methods for Collections:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8048330
>>
>> Brief background: several times over the years there have been proposals to
>> add "collection literals" to the language. The most recent round of this was
>> in regard to JEP 186, a research JEP to explore this topic. That effort was
>> concluded by Brian Goetz, as summarized in this email:
>>
>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html
>>
>> Essentially, the idea of adding collection literals to the language was set
>> aside in favor of adding some library APIs, not entirely unlike collection
>> literals, that make it more convenient to create collections. That's what this
>> proposal is.
>
> I think you should say something about the serialization of the immutable
> collections
> because implementation details like the real class name can leak through this
> channel.
> That's why, by example, java.util.Collections.ArrayList (the internal class of
> Collections) was never renamed.

Hi Remi,

(I think you mean java.util.Arrays.ArrayList?)

But yes, the point is make the implementation classes private and to use 
serialization proxies (or perhaps just one serialization proxy for all 
implementation classes) to control the number of classes exposed by the 
serialized format. I should probably make this more explicit.

> Also 5 key/value pairs seems a little bit limited IMO, 7 or 8 will be better but
> I suppose you want to use the fact
> that because the number of pairs is really small, the algorithm can do a linear
> probe.

We started with 5 because that's what Guava does, but there's nothing essential 
about 5. Could be 6 or 7 or maybe even 8. We need to do some investigation of 
common map sizes in real applications. That's how the Guava guys came up with 5, 
I think. We have some internal numbers that I'm told are slightly higher, but I 
still need to track those down.

And yes at small sizes it makes sense to do linear probe or even a plain linear 
search (i.e., no hashing).

> I think you should add a version that takes two arrays of the same size (for an
> (almost) unlimited number of pairs)
> with an implementation that clone the two arrays (at least until value type are
> implemented).

Yes, one could add such a thing. :-) I guess if we were to choose the right 
number of key/value pairs for Map.of(...), would there still be a need for 
immutable maps with arbitrary numbers of key-value pairs? And how convenient 
would it be to use?

> I think you should also add a default method toImmutable to Set, List and Map,
> so one  can use HashSet, ArrayList
> and HashMap as builder for their immutable counterparts. Otherwise, the stream
> integration will be difficult,
> i.e. the implementation of Collectors.toImmutableList/Set/Map.

I don't see this proposal as providing immutable counterparts to the existing 
mutable collections. The existing collections are designed to deal well with 
arbitrary numbers of elements, but the immutable collections discussed here are 
not -- they're intended to support the convenience API, which is focused on 
relatively small numbers of elements.

Now it might be nice to have a set of scalable, immutable collections, which 
would necessarily entail some additional APIs to construct them from streams and 
from existing collections. But that's a somewhat different goal. We should have 
a discussion about whether doing that is necessary, and if so, whether it should 
be part of this proposal.

s'marks