please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

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