Libraries updates for extensions methods

[Rémi Forax]

A beta version of tiger (1.5) tries to introduce a ReadOnlyIterator,
see 
http://www.jcp.org/aboutJava/communityprocess/jsr/tiger/enhanced-for.html

It was removed for the first public draft of of JSR 201 (which 
introduces foreach loop)

Here is the relevant quote from the design FAQ.

*What happened to theSimpleIterator/ReadOnlyIteratorinterface present in 
earlier drafts of this specification?*

We found a deep problem with the design that could only be fixed by 
using the preexistingIteratorinterface. To make a long story short, 
because the JVM represents a method using a signature that includes the 
return type, the retrofit toCollectioninterface had the effect (from the 
VM's point of view) of/adding/a method to Collection. This method is 
normally created silently by the compiler so the user doesn't have to 
worry about it - it's called a/bridge method/. Implementations 
ofCollectionthat were compiled using a pre-1.5 compiler lack this bridge 
method, causing them to fail at runtime with anAbstractMethodError. 
Simply put, we violated the basic rule that one cannot add a method to a 
public interface.

cheers,
Rémi

On 08/13/2012 06:16 PM, Brian Goetz wrote:
> 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.
>>