please review draft JEP: Convenience Factory Methods for Collections (original) (raw)
Steven Schlansker stevenschlansker at gmail.com
Thu Jul 17 17:17:02 UTC 2014
- Previous message: please review draft JEP: Convenience Factory Methods for Collections
- Next message: please review draft JEP: Convenience Factory Methods for Collections
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jul 16, 2014, at 5:46 PM, Stuart Marks <stuart.marks at 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
- Previous message: please review draft JEP: Convenience Factory Methods for Collections
- Next message: please review draft JEP: Convenience Factory Methods for Collections
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]