Often there is the need to setup an ArrayList<>. One of the constructors takes a collection, but there is no constructor that takes an iterator.
What if I have an iterator? Is there a way to "reach up" to the collection that offers the iterator in order to use the ArrayList<> constructor?
Specifically I have the iterator offered by PropertiesConfiguration.getKeys() which is part of org.apache.commons.
There's no such thing, an Iterator's Collection. An Iterator can be created independently of a Collection. It can be obtained from any Iterable, or you can even create a class implementing an iterator.
However, you can obtain an ArrayList from an Iterator by iterating it and adding its elements one by one:
Iterator<X> it = ...;
List<X> list = new ArrayList<X>();
while (it.hasNext()) {
list.add(it.next());
}
Note, however, that this cannot be done reliably for every possible iterator, since there's the possibility that an iterator will iterate forever, thus causing an infinite loop and most probably an OutOfMemoryError.
I'd suggest you take a look at Google Guava, an utility library from Google. It has a class called Lists, which allows you to do the following:
Iterator<X> it = ...;
List<X> list = Lists.newArrayList(it);
The library has tons of methods extremely useful for everyday Java coding. It contains mostly everything you want but cannot find in the standard Java 6 API.
There is no truly general way to do this, because in Java, Iterator is just an interface with three methods: next, hasNext and remove.
When you obtain an iterator, you use a factory method that gives you an instance of some class implementing the interface. If you know the specific class, you can look at its documentation or source to find if there is a way to find the collection it is iterating over.
But there are many such classes. In the case of ArrayList, look in the source code to see what kind of iterator you are getting.
EDIT:
Here is the source code for ArrayList in Open JDK 7: http://www.docjar.com/html/api/java/util/ArrayList.java.html
The iterator over an ArrayList is an instance of the private inner class Itr. This should not be too surprising. The iterator comes from a factory method, after all, so you're really not supposed to know what kind of iterator you are getting. In fact, if you were able to get the class of this instance and access its methods (say, via reflection) you would be doing a bad thing. This iterator is part of the (internal) implementation of the ArrayList class and (as #merryprankster points out) can change in the future.
I don't know if its possible, but in my opinion, a such function should not exist because an iterator may not come from a collection. For example, one could create an iterator which chains over multiple collections !
Related
Few days ago I had a struggle with a strange bug, that occurred in my map reduce task.
Finally, it turned out that hadoop ValueIterable class that implements Iterable interface creates a single instance of iterator and returns it on every call of iterator() method.
protected class ValueIterable implements Iterable<VALUEIN> {
private ValueIterator iterator = new ValueIterator();
#Override
public Iterator<VALUEIN> iterator() {
return iterator;
}
}
That means if you iterate over ValueIterable once, you are not able to iterate it again.
I decided to check java documentation and seems that it does not require Iterable to return different iterators every time (or just missing the requirement?). Diving deeper I found this answer telling that having a single iterator violates Iterator contract, since it can not traverse the collection more than once.
Who is correct here? Should Iterable return new iterators? Why are java docs unclear?
What would be the correct way for this hadoop class to tell client that traverse is impossible? I mean if it will throw IllegalStateException, would it violate Iterator#hasNext() method contract?
From here:
The Iterator you receive from that Iterable's iterator() method is special. The values may not all be in memory; Hadoop may be streaming them from disk. They aren't really backed by a Collection, so it's nontrivial to allow multiple iterations.
There is no actual defined contract that states that each Iterator returned by Iterable.iterator() should repeat the same sequence. This is only a custom because it is expected behaviour.
Hadoop - or any other library - is therefore allowed to break the rules on this.
The java docs are unclear for exactly this purpose - to let the implementors of Iterable have the wiggle room to do it any way they want.
How you should do it - like the other answers mentioned in the link - retain a list of already iterated items for a later repeat iteration - but be warned, this may be a huge collection in a live hadoop environment so you may well break.
The Enumeration interface of java has 2 methods
hasNext()
next()
Why doesn't Iterator extend Enumeration and add the remove method()?
Also, if all I want to do is loop over my collection, I can make do with an Enumeration (or an iterator if it extends enumeration) as loop statements only need an enumeration. I don't have to worry about the collection getting modified
Why doesn't Iterator extend Enumeration and add the remove() method?
From the documentation:
Iterator takes the place of Enumeration in the Java Collections Framework. Iterators differ from enumerations in two ways:
Iterators allow the caller to remove elements from the underlying collection during the iteration with well-defined semantics.
Method names have been improved.
I suspect the latter is the real reason for introducing a brand new interface instead of extending the existing one.
Also, if all I want to do is loop over my collection, I can make do with an Enumeration (or an iterator if it extends enumeration) as loop statements only need an enumeration. I don't have to worry about the collection getting modified
Well, if you don't want to modify the collection, then don't call remove(). If you really, really don't trust yourself, you could use Collections.unmodifiableCollection() et al to create a read-only wrapper.
Finally, it is worth noting that if you use a for-each loop to iterate over the collection, you don't have access to the remove() method anyway:
for (String s : str_list) {
...
}
Here, we are using the Iterator interface, but don't have access to the actual iterator object.
You could just obtain a java.util.Enumerator from your collection, via the java.util.Collections.enumeration() Method.
Anyway, if you don't want to modify your collection via its iterator, it's just a matter of not calling the remove() method.
According to http://www.journaldev.com/1330/java-collections-interview-questions-and-answers#iterator-vs-enumeration, "Enumeration is twice as fast as Iterator and uses very less memory. Enumeration is very basic and fits to basic needs."
So, I guess if you don't need remove(), then using Enumeration is more effective than using Iterator.
The question might be pretty vague I know. But the reason I ask this is because the class must have been made with some thought in mind.
This question came into my mind while browsing through a few questions here on SO.
Consider the following code:
class A
{
private int myVar;
A(int varAsArg)
{
myVar = varAsArg;
}
public static void main(String args[])
{
List<A> myList = new LinkedList<A>();
myList.add(new A(1));
myList.add(new A(2));
myList.add(new A(3));
//I can iterate manually like this:
for(A obj : myList)
System.out.println(obj.myVar);
//Or I can use an Iterator as well:
for(Iterator<A> i = myList.iterator(); i.hasNext();)
{
A obj = i.next();
System.out.println(obj.myVar);
}
}
}
So as you can see from the above code, I have a substitute for iterating using a for loop, whereas, I could do the same using the Iterator class' hasNext() and next() method. Similarly there can be an example for the remove() method. And the experienced users had commented on the other answers to use the Iterator class instead of using the for loop to iterate through the List. Why?
What confuses me even more is that the Iterator class has only three methods. And the functionality of those can be achieved with writing a little different code as well.
Some people might argue that the functionality of many classes can be achieved by writing one's own code instead of using the class made for the purpose. Yes,true. But as I said, Iterator class has only three methods. So why go through the hassle of creating an extra class when the same job can be done with a simple block of code which is not way too complicated to understand either.
EDIT:
While I'm at it, since many of the answers say that I can't achieve the remove functionality without using Iterator,I would just like to know if the following is wrong, or will it have some undesirable result.
for(A obj : myList)
{
if(obj.myVar == 1)
myList.remove(obj);
}
Doesn't the above code snippet do the same thing as remove() ?
Iterator came long before the for statement that you show in the evolution of Java. So that's why it's there. Also if you want to remove something, using Iterator.remove() is the only way you can do it (you can't use the for statement for that).
First of all, the for-each construct actually uses the Iterator interface under the covers. It does not, however, expose the underlying Iterator instance to user code, so you can't call methods on it.
This means that there are some things that require explicit use of the Iterator interface, and cannot be achieved by using a for-each loop.
Removing the current element is one such use case.
For other ideas, see the ListIterator interface. It is a bidirectional iterator that supports inserting elements and changing the element under the cursor. None of this can be done with a for-each loop.
for(A obj : myList)
{
if(obj.myVar == 1)
myList.remove(obj);
}
Doesn't the above code snippet do the same thing as remove() ?
No, it does not. All standard containers that I know of will throw ConcurrentModificationException when you try to do this. Even if it were allowed to work, it is ambiguous (what if obj appears in the list twice?) and inefficient (for linked lists, it would require linear instead of constant time).
The foreach construct (for (X x: list)) actually uses Iterator as its implementation internally. You can feed it any Iterable as a source of elements.
And, as others already remarked: Iterator is longer in Java than foreach, and it provides remove().
Also: how else would you implement your own provider class (myList in your example)? You make it Iterable and implement a method that creates an Iterator.
For one thing, Iterator was created way before the foreach loop (shown in your code sample above) was introduced into Java. (The former came in Java2, the latter only in Java5).
Since Java5, indeed the foreach loop is the preferred idiom for the most common scenario (when you are iterating through a single Iterable at a time, in the default order, and do not need to remove or index elements). Note though that the foreach uses an iterator in the background for standard collection classes; in other words it is just syntactic sugar.
Iterator, listIterator both are used to allow different permission to user, like list iterator have 9 methods but iterator have only 3 methods, but have remove functionality which you can't achieve with for loop. Enumeration is another thing which is also used to give only read permissions.
Iterator is an implementation of the classical GoF design pattern. In that way you can achieve clear behaviour separation from the 'technical code' which iterates (the Iterator) and your business code.
Imagine you have to change the 'next' behaviour (say, by getting not the next element but the next EVEN element). If you rely only on for loops you will have to change manually every single for loop, in a way like this
for (int i; i < list.size(); i = i+2)
while if you use an Iterator you can simply override/rewrite the "next()" and "hasNext()" methods and the change will be visible everywhere in your application.
I think answer to your question is abstraction. Iterator is written because to abstract iterating over different set of collections.
Every collection has different methods to iterate over their elements. ArrayList has indexed access. Queues has poll and peek methods. Stack has pop and peek.
Usually you only need to iterate over elements so Iterator comes into play. You do not care about which type of Collection you need to iterate. You only call iterator() method and user Iterator object itself to do this.
If you ask why not put same methods on Collection interface and get rid of extra object creation. You need to know your current position in collection so you can not implement next method in Collection because you can not use it on different locations because every time you call next() method it will increment index (simplifying every collection has different implementation) so you will skip some objects if you use same collection at different places. Also if collection support concurrency than you can not write a multi-thread safe next() method in collection.
It is usually not safe to remove an object from collection iterating by other means than iterator. Iterator.remove() method is safest way to do it. For ArrayList example:
for(int i=0;i
Why? And what the best way to move iterator items pointer to the first position?
Why?
Because if you force iterator to have a reset method every iterator has to have a reset method. That gives every iterator writer extra work. Plus some iterators are really hard (or really expensive) to reset, and you wouldn't want users to call reset on them. Iterators over files or streams are good examples.
what the best way to move iterator items pointer to the first position?
Create a new iterator. It's rarely more expensive than the reset.
Once you read a stream, you can't re-read it without opening the source again. That's how streams and iterators work.
The best way is to create a new one!
This is a general tendency adopted in JCF - keep the interface minimalistic , unless that makes some feature extremely difficult to work. This is the reason why you do not have separate interfaces for semantics like immutable collections, fixed-size collections ..
As to why then a remove(Object) is provided ( as optional ) - Not providing this would make it impossible to safely remove an item from a collection while iterating over the collection - there is nothing that makes providing a reset() so compulsary.
Again , why there is a separate ListIterator() ( providing methods like previous() and previousIndex() ) - With a List interface , the main functionality while it is being used is the ability to layout the elements wrt an index, and to be able to access them with an index-order , whether fixed or random order. This is not the case with other collections.Not providing this interface for a List will make it very difficult if not impossible to work smoothly with a list.
Tip: create your iterator variable as a function instead, then you can consume it as many times are you want. This only works if the underlying logic is repeatable.
Example in Scala (Java similar but I don't have a Java REPL handy)
def i = (1 to 100) iterator // i is our iterator
i.grouped(50) foreach println // prints two groups
i.grouped(50) foreach println // prints same two groups again
Say I want to work with a linked list in java. I thought that the best way to create one is by:
List list = new LinkedList();
But I noticed that this way I can only use methods on the list that are generic. I assume that the implementation is different among the different data structures.
So if I want to use the specific methods for linked list, I have to create the list by:
LinkedList list = new LinkedList();
What's the main reason for that?
Tnanks.
List is an interface that abstracts the underlying list implementation. It is also implemented by e.g. ArrayList.
However, if you specifically want a LinkedList, there is nothing wrong with writing LinkedList list. In fact, if you just pass it around as a list, people may (not knowing the implementation) unknowingly write algorithms like:
for(int i = 0; i < list.size(); i++)
{
// list.get(i) or list.set(i, obj)
}
which are linear on a random access list (e.g. ArrayList) but quadratic on a LinkedList (it would be preferable to use a iterator or list iterator). Java provides the RandomAccess marker interface so you can distinguish.
Of course, you can call these methods on a reference of type LinkedList too, but people should be more likely to consider the cost.
As a note, in .NET LinkedList does not implement IList for this reason.
The first idiom allows you to change the runtime type that list points to without modifying any client code that uses it.
What methods in LinkedList do you think you need that aren't in List? You can always cast for those.
But the whole idea behind interfaces is to shield clients from how the interface is implemented.
If you really need a LinkedList, so be it. But I prefer the first idiom, because most of the time I really just need List methods.
Every LinkedList is a List, too. That also means that you can do everything with a LinkedList that you can do with a List and that you can store a LinkedList as List. However, when you store it as List, you can only call methods of the LinkedList that a List also has.
By the way: This is not Generics. Generics are like this:
LinkedList<String> list = new LinkedList<String>();
List list = getSomeList();
Here you're saying that it's a list. You have no idea whether or not it's a LinkedList or an ArrayList or whatever. It is an abstract thing (I assume you mean "abstract" by the word "generic", since generics are a different thing entirely). Thus you can't treat it like it's an LinkedList -- you have to treat it like it's a List (which it is).
The fact that "you know" that it's a LinkedList is all well and good, and you can safely cast if you need to do it. But it might help to tell the compiler that it's a LinkedList, by declaring it as so, if it's always going to act as a LinkedList.