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.
Cheers, Paul On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks <stuart.ma...@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 > > >
