Working with immutable collections

[Brian Goetz]

That's on the list.  (Similar for synchronized()).

Unfortunately, it's trickier than it looks, because of inheritance 
diamonds.  LinkedList implements List and Queue, so when you try to 
inherit unmodifiable() from both List (returns List) and Queue (returns 
Queue), you have to override it with something that returns both a List 
and a Queue.  Unfortunately this means reimplementing Unmodifiable for 
ad-hoc intersections like List&Queue.  We can work around this one by 
leaving List in the cold, but we still find landmines.  For example, 
there's a stupid class in the JDK that implements both List and Set (for 
bad reasons) and that happens to be serializable so we can't even fix it 
easily.  Having the same problem with List and Set is particularly 
annoying because you cannot simultaneously implement the contract of 
List and Set!  But that didn't stop whoever wrote this class.

So what sounds like a no-brainer is actually more work than it looks.

On 11/19/2012 10:07 AM, Gernot Neppert wrote:
> I'd rather have an "unmodifiable" member function in
> java.util.Collection, together with a "synchronized" function, something
> like this:
>
> public interface Collection<E> {
>
> /**
>     Returns an unmodifiable view of this Collection.
>     @return an unmodifiable view of this Collection (may be {@code this}
> instance if is already unmodifiable).
> public Collection<E> unmodifiable() default {
>         return Collections.unmodifiableCollection(this);
>       }
>
> /**
>     Returns a synchronized view of this Collection.
> @param lock the Lock to use.
>     @return a view of this Collection that executes all operations while
> holding a Lock. (may be {@code this} instance if is already synchronized
> on the supplied Lock).
> @throws IllegalArgumentException if this Collection is already
> synchronized on a different Lock.
> public Collection<E> synchronize(Lock lock) default {
>         return Collections.synchronize(this, lock);
>       }
>
> }
>
>
> These should of course be co-variantly overriden in java.util.List,
> java.util.Set etc.!
>
>
>
>
>
>
> Am 19.11.2012 15:39, schrieb Johan Haleby:
>> Hi,
>>
>> I'm sorry if this has been discussed before but here goes:
>>
>> Let's say I have an immutable list called "xList" that I want to filter and
>> return the result as a new *immutable* list. I could do something like this:
>>
>> Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new
>> ArrayList<X>())));
>>
>> How ever I think this is quite verbose and doesn't follow the fluent style
>> of the API. What I would like to have is something a long these lines:
>>
>> xList.filter(obj -> obj.something()).intoImmutable(new ArrayList<X>()));
>>
>> "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so
>> I don't need to wrap all statements where I want to return an immutable
>> collection.
>>
>> What are your thoughts on this?
>>
>> Regards,
>> /Johan
>>
>
>