On Jul 16, 2014, at 5:46 PM, Stuart Marks <stuart.ma...@oracle.com> wrote:
> Hi all, > > 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. This is fantastic, I think a large number of developers will cheer as more and more of Guava makes it into core libs :) One thing I notice is that you take a lot of care to not specify how the Map or Set will be implemented. This could be troublesome because different implementations have different requirements for keys — e.g. HashMap requires hashCode()/equals() but SortedMap requires compareTo(). It seems unlikely that the implementation could reasonably require anything other than equals() and maybe hashCode(), but given the headache created by over/underspecifying maybe clarifying this is worth considering. As another note, you briefly mentioned immutable implementations of Map, Set, and List. These types are well worth adding to the JDK in my opinion - if you try to design an immutable data structure containing such types, you are forced to make many defensive copies to ensure they cannot later be modified. With immutable implementations, defensive copies are trivially cheap or free, which is a great boon to library maintainers. Looking forward to being able to use this! Steven
