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.ma...@oracle.com> > À: "core-libs-dev" <core-libs-dev@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 >
