please review draft JEP: Convenience Factory Methods for Collections

[Remi Forax]

On 07/17/2014 04:05 AM, Paul Benedict wrote:
> Regarding why you didn't choose a straight vararg solution, I prefer 
> you do allow any number of key/values as long as you throw an 
> exception if the array is not an even sized.

You can not extract/infer the type of the key and the type of the value 
if you have only one array.

>
>
> Cheers,
> Paul

cheers,
Rémi

>
>
> On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks <stuart.marks at oracle.com 
> <mailto:stuart.marks at oracle.com>> wrote:
>
>     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
>
>
>