Users of Iterable expect to call Iterable.iterator() multiple times, receiving a fresh iterator pointing to the beginning of the Iterable each time. This would not be possible to do with an Enumeration wrapper since Enumerations are read-once.

I don't know if this is a strong enough reason not to include such a utility class, but it could certainly be confusing.

-Sasha

On 8/3/2011 2:09 PM, Neil Richards wrote:
On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote:
Please see my responses inline.

Thanks!
-Sasha

On 8/2/2011 9:13 PM, Xuelei Fan wrote:
. com/sun/jndi/toolkit/dir/SearchFilter.java
   451         for (NamingEnumeration<?>   ve = attr.getAll();
   452              ve.hasMore();
   453                ) {

The update is OK. But the coding style looks uncomfortable. Would you
mind change it to use for-each style?
For-each only works with Iterables. There doesn't seem to be a way to
get an Iterable out of an Attribute instance, so the only way to use a
for-each here would be to wrap the Enumeration in an ArrayList using
Collections.list(). While this might look neater, the contents of the
Enumeration would have to be copied over, using time and increasing the
memory footprint. Changing Attribute to implement Iterable would require
a spec change, and would be beyond the scope of this fix.
Would it  be useful to have a utility object to convert an Enumeration
so it can be used in for-each constructs? - something like:
----
         import java.util.Enumeration;
         import java.util.Iterator;

         /**
          * Utility class to transform an Enumeration object such that it can 
be used in
          * the for-each construct.
          */
         public class IterableEnumerationHolder<E>  implements Iterable<E>, 
Iterator<E>  {
             private final Enumeration<E>  e;

             public IterableEnumerationHolder(final Enumeration<E>  e) {
                 this.e = e;
             }

             @Override
             public Iterator<E>  iterator() {
                 return this;
             }

             @Override
             public boolean hasNext() {
                 return e.hasMoreElements();
             }

             @Override
             public E next() {
                 return e.nextElement();
             }

             @Override
             public void remove() {
                 throw new UnsupportedOperationException();
             }
         }
----

If it would, perhaps it might be considered for Java 8?

Regards,
Neil

Reply via email to