please review draft JEP: Convenience Factory Methods for Collections
forax at univ-mlv.fr
Thu Jul 17 08:53:04 UTC 2014
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.
> 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:
> 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:
> 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
> because implementation details like the real class name can
> leak through this
> 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
> 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
> 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.
More information about the core-libs-dev