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.ma...@oracle.com <mailto: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
