RFR: updated draft API for JEP 269 Convenience Collection Factories

Stephen Colebourne scolebourne at joda.org
Sat Nov 7 03:53:00 UTC 2015

I haven't reviewed in detail, but it seems like the right set of
methods. There may be a case for adding equivalent to Queue, Deque,
NavigableSet and SortedSet, if not now maybe in the future, although
their usage is markedly lower.


On 6 November 2015 at 02:13, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi all,
> Sorry for the hiatus. I had this thing called JavaOne that I had to deal
> with....
> Please review this updated draft API and implementation. Highlights of
> changes are:
>  - factory methods removed from concrete collections
>  - renamed Map.fromEntries() to Map.ofEntries()
>  - increased List.of() and Set.of() fixed-arg overloads to ten elements,
>    and Map.of() to ten key-value pairs
>  - updated specs to clarify that nulls are disallowed and that duplicate
>    Set elements and Map keys are disallowed
>  - removed KeyValueHolder from the public API and adjusted Map.entry()
>    to return Map.Entry
>  - value-based and other stipulations added to Map.entry() specification
>  - inclusion of skeletal implementation and tests
>  - spec updates and cleanups
> Regarding the number of fixed-arg overloads, having five List and Set
> elements seemed too few, and even eight key-value pairs for Map seemed too
> few. I've somewhat arbitrarily chosen ten elements and pairs. It seems high
> enough to catch most cases with the fixed-arg overloads, and we still have
> the varargs as an escape hatch.
> The implementations are "skeletal" in that they simply use the existing
> collection implementations wrapped by the unmodifiable wrappers where
> appropriate. This should be sufficient to vet the API and to pass all the
> tests. The main deficiency with these implementations is that they're
> serializable but their serial form isn't final. And of course they don't
> deliver any of the promised space efficiencies.
> My plan is to try to converge on the API specification and integrate it into
> jdk9-dev along with the skeletal implementations over the next couple weeks.
> This should allow test development and writing of examples and such to
> proceed. The space-efficient implementations, and a revised serial form
> (using serialization proxies), will come after that.
> I'll be at Devoxx Antwerp next week so there will likely be some delay in my
> responses on this list. But I might see some of you there as well. If so,
> please say hi! In any case I'll pick this up mid-November and continue
> moving it forward.
> Javadoc:
>         http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151105/
> Specdiff:
> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151105/java/util/package-summary.html
> Webrev:
>         http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151105/
> Thanks,
> s'marks

More information about the core-libs-dev mailing list