RFR: updated draft API for JEP 269 Convenience Collection Factories
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
> 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.
More information about the core-libs-dev