JEP 186: Collection Literals

Jochen Theodorou blackdrag at
Fri Jan 31 02:33:33 PST 2014

Am 31.01.2014 10:02, schrieb Remi Forax:
> On 01/31/2014 09:59 AM, Jochen Theodorou wrote:
>> Am 31.01.2014 09:43, schrieb Remi Forax:
>> [...]
>>> If one day the JDK has persistent collections (and I hope it will),
>>> there will be not interface to abstract them.
>>> (you can still ask all implementations in the javadoc of the interface
>>> to super swear that they are immutable but it's a weak contract).
>> But the same goes for an abstract base class. So those persistent
>> collections would always have to have only the concrete class and most
>> probably no super class besides Object.
>> Supporting different implementations then becomes difficult.
> if the abstract class is public, yes, but you can make it non public,
> like by example the abstract class between StringBuilder and StringBuffer.

I may not have said it right... implementation wise you can do a lot 
with a delegation model if you have to and not use inheritance. So for 
implementing those classes it is most probably not a problem.

I was thinking of the user side. For example let's say there is an 
implementation of a persistent list (or set) with a contains method. 
There are different possible implementations for that. But if there is 
no abstraction of the type anymore, the user code can only depend on a 
concrete type.

You can move different implementations into a single class. Then, the 
"instantiator" of the instance could choose the implementation by 
argument for example. The problem is, that this does not allow user 
implementations at all.

I use for example a hash array mapped trie as persistent map. There are 
sure other implementations that make sense out there in for other 
scenarios. It would not be feeling right, not allowing user 
implementations at all

bye Jochen

Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit

More information about the lambda-dev mailing list