On 7/17/14 10:17 AM, Steven Schlansker wrote:
This is fantastic, I think a large number of developers will cheer as more and more of Guava makes it into core libs :)
Great!
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.
First, I should clarify that these are static factory methods on the interfaces, not default methods. Thus they aren't inherited, and there won't be any complications arising from additional subinterface requirements, such as how SortedMap requires elements to be Comparable. (Unless a comparator is provided, etc.)
The implementations of instances returned by these factory methods fulfil just the basic interfaces. In particular, the notion of duplicate elements or keys for Set and Map are defined by equals(), so that's all they have to support.
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.
Yes, I certainly see the value in having implementations of immutable collections. There would be some relationship to this "convenience factories" project, but they aren't necessarily the same thing. If a couple really useful immutable implementations could be slipped in, sure, it might work out. But if it turns into a big design discussion with lots of different implementations -- consider ImmutableHashMap, ImmutableTreeMap, etc. -- then it begins to sound like a different effort.
s'marks
