Libraries updates for extensions methods

[Brian Goetz]

It would have been better to do this from the beginning, but I think 
this ship has mostly sailed.  There are three choices:

  - II extends I
  - I extends II
  - Neither extends each other

The third choice is a failure because they can't be interchanged with 
existing APIs.

 From a strict method-subsetting perspective, I should extends II.  But 
that would violate the contract of immutability inherent in the name.

An abstract class ImmutableIterator with a final throwing remove method 
might be a reasonable implementation convenience.  But putting a default 
on remove is better, since it doesn't burn your single class inheritance 
slot just to get a trivial implementation of remove.

On 8/13/2012 12:12 PM, "Zdeněk Troníček" wrote:
> Concerning the Iterator, I was always curious why there is not any class
> ImmutableIterator with method remove() throwing UOE.
>
> I found 89 implementations of Iterator in JDK 7.
> 35 of them implements remove() as { throw new UOE(); }.
> 29 out of these 35 implement directly Iterator, 6 implement ListIterator.
> 34 out of 35 could use ImmutableIterator or ImmutableListIterator because
> they are either anonymous subclasses or classes that do not have any
> explicit superclass.
> Only once (CorbaContactInfoListIteratorImpl) this is not possible.
>
> Wouldn't be the class ImmutableIterator more stylish?
> (The numbers are without any warranty. I have not done any double check.)
>
> Z.
>