1.8/1.9: Iterator and ListIterator optional operations

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

1.8/1.9: Iterator and ListIterator optional operations

Volker.Borchert
Sorry for this more-or-less off-topic post, but I couldn't find any discussion
on this (thank you G**gle for tryimg to outsmart your users).

With 1.8, Iterator's remove() has become a default methods that throws
UnsupportedOperationException. But ListIterator's add(), set(), and remove()
have stayed abstract, the latter even hiding Iterator's.

Why? I.o.w., is there any hope this will change?

Thank you for any enlightnment

        Volker

////////////////////////////////////////////////////////////////////

ATIS systems GmbH
Sitz: Bad Homburg
Registergericht: Bad Homburg HRB 1514
Geschaeftsfuehrer: Stefan Diepolder, Daniel Sieh
 
________________________________________________________________________________________________

This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received this message by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from ATIS systems GmbH may be monitored to ensure compliance with internal policies and to protect our business. E-Mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed. Anyone who communicates with us by e-mail is taken to accept these risks.




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: 1.8/1.9: Iterator and ListIterator optional operations

Joshua Bloch
That's a very good question. I definited all of these methods, and haven't a clue.

Josh

P.S. I also the that default methods were a big mistake, so perhaps my cluelessnes is irrelevant.

On Tue, Nov 17, 2015 at 3:30 AM, <[hidden email]> wrote:
Sorry for this more-or-less off-topic post, but I couldn't find any discussion
on this (thank you G**gle for tryimg to outsmart your users).

With 1.8, Iterator's remove() has become a default methods that throws
UnsupportedOperationException. But ListIterator's add(), set(), and remove()
have stayed abstract, the latter even hiding Iterator's.

Why? I.o.w., is there any hope this will change?

Thank you for any enlightnment

        Volker

////////////////////////////////////////////////////////////////////

ATIS systems GmbH
Sitz: Bad Homburg
Registergericht: Bad Homburg HRB 1514
Geschaeftsfuehrer: Stefan Diepolder, Daniel Sieh

________________________________________________________________________________________________

This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received this message by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from ATIS systems GmbH may be monitored to ensure compliance with internal policies and to protect our business. E-Mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed. Anyone who communicates with us by e-mail is taken to accept these risks.




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: 1.8/1.9: Iterator and ListIterator optional operations

Brian Goetz-3
In reply to this post by Volker.Borchert
The story with remove() is an unfortunate combination of tooling
limitations and oversight; ListIterator explicitly redeclares remove()
not because it wants to override it for any actual reason (e.g., to add
annotations), but instead because that's how you get to "override" the
Javadoc.  We should have noticed this when adding the default to remove,
since the same rationale about remove being effectively optional applies
to ListIterator as well as Iterator.  And a similar argument could be
made about set and add, not unlike the behavior of the mutative methods
in AbstractCollection, which default to throwing UOE.


On 11/17/2015 6:30 AM, [hidden email] wrote:

> Sorry for this more-or-less off-topic post, but I couldn't find any discussion
> on this (thank you G**gle for tryimg to outsmart your users).
>
> With 1.8, Iterator's remove() has become a default methods that throws
> UnsupportedOperationException. But ListIterator's add(), set(), and remove()
> have stayed abstract, the latter even hiding Iterator's.
>
> Why? I.o.w., is there any hope this will change?
>
> Thank you for any enlightnment
>
> Volker
>
> ////////////////////////////////////////////////////////////////////
>
> ATIS systems GmbH
> Sitz: Bad Homburg
> Registergericht: Bad Homburg HRB 1514
> Geschaeftsfuehrer: Stefan Diepolder, Daniel Sieh
>
> ________________________________________________________________________________________________
>
> This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received this message by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from ATIS systems GmbH may be monitored to ensure compliance with internal policies and to protect our business. E-Mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed. Anyone who communicates with us by e-mail is taken to accept these risks.
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: 1.8/1.9: Iterator and ListIterator optional operations

Joshua Bloch


On Fri, Nov 20, 2015 at 1:09 PM, Brian Goetz <[hidden email]> wrote:
The story with remove() is an unfortunate combination of tooling limitations and oversight; ListIterator explicitly redeclares remove() not because it wants to override it for any actual reason

I missed this when you wrote it, but i'd like to take issue with it: ListIterator overrides remove for the best of reasons: it refines the superclass (interface) contract. That is the quintessential reason for overriding an interface method.

Josh

P.S. Happy Thanksgiving, all.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest