RFR: updated draft API for JEP 269 Convenience Collection Factories

[Remi Forax]

Hi Stuart,
reading the documentation, 
methods of() are implementing the *static* method factory pattern (introduced by Josh Blosch in Effective Java) not the "method factory pattern" which something else in the GoF [1] (and should not be used BTW).

Rémi

[1] https://en.wikipedia.org/wiki/Factory_method_pattern

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 6 Novembre 2015 03:13:12
> Objet: RFR: updated draft API for JEP 269 Convenience Collection Factories
> 
> 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
>