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