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
