title: Lack of certainty in Circular linked list and Iterator API
body: <p>I am trying to create a  circular linked list implementation using <code>List</code> interface, and have noticed an interesting side effect.</p>
  
  <p>Though the <code>CircularLinkedList</code> satisfies the List contract, it breaks the 
  other currently implemented <code>collection</code> classes!</p>
  
  <p>The problem is this - the ListIterator interface gives the following 
  contract for the hasNext() and hasPrevious() methods:</p>
  
  <blockquote>
    <p>public boolean <strong>hasNext()</strong></p>
    
    <p>Returns true if this list iterator has more elements when 
       traversing the list in the forward direction. (In other words, returns 
       true if next would return an element rather than throwing an exception.)</p>
    
    <p>public boolean <strong>hasPrevious()</strong></p>
    
    <p>Returns true if this list iterator has more elements when 
       traversing the list in the reverse direction. (In other words, returns 
       true if previous would return an element rather than throwing an exception.)</p>
  </blockquote>
  
  <p>Now in a circular list, each of these should by the contract return <strong>false</strong> if and only if the List is empty. </p>
  
  <p>The problem shows itself when you try to add a circular list with the appropriate list iterator to another Collection using the <strong>addAll()</strong> method - the method uses <strong>hasNext()</strong> to constrain the iteration as it adds each element. Hence the 
  loop never terminates!</p>
  
  <p>I am currently thinking of breaking the contract of either the ListIterator, to make the list look like a linked list if you are looking at the hasNext() method, or creating a subclass of the iterator with hasNext overridden to be returned by the iterator() method.</p>
  
  <p>Two questions:</p>
  
  <ol>
  <li><p>Is there a better way of doing this without breaking the Iterator
  or  ListIterator contracts? </p></li>
  <li><p>Does anyone else think that this is a flaw in the AbstractCollection  class (which is where the inherited behaviour comes from). Note that  some collections do perform the adding in a more robust way, by calling  the toArray() method of the collection to be added, and adding each  element of the array.</p></li>
  </ol>