Use Enumeration/Iterator OR array?

hi all,
i've a question. what would be pros/cons of using an Enumerator/Iterator based traversin vs. array.
i've this question as i've a scenario where i have multiple objects of the same type needs to be returned. should i use array? or should i use a structure that can be accessed via enumerator/iterator?
i've 2 points in mind regarding this. please vote more points in +ve/-ve side for any.
1. array: might run into array index bounds problems
2. array: will be easy to access via indexes
i don't see any major significant usage issues with any of them.
what would be a better approach?
regards
maulin.

Peter Haggar discussed it's pro and con in his book "Practical Java", its listed as praxis #39 & #41.
-Ryo
[ April 07, 2003: Message edited by: Ryo Saeba ]

You should always use arrays if you can. They are always more efficient than any Collection object for simply iterating through the array.

hi,
thanks Thomas. i'll use array.
hi Ryo, can you please quote something important from the book as i don't have that book?
thank you.
maulin.

Use array if you can is good advice for performance.
When can't you? What can Collections do that an array can't? Insert, grow, delete, sort, prevent duplicates come to mind. More?

I think this is probably an example of premature optimization. Statistically, the bottleneck in your code will probably be somewhere else, and it won't matter much how good the performance of your iteration is. If it turns out that that iteration speed for your collection/array really is critical, and you don't need good performance when inserting/deleting, then yes, use an array (rewriting if necessary). But most of the time, I think the power and flexibility of the List interface makes it the preferred choice.
What can Collections do that an array can't? Insert, grow, delete, sort, prevent duplicates come to mind. More?
First, some more benefits to arrays. Contrary to the previous post, you can sort arrays by using the Arrays.sort() methods. If you're really motivated, you can even make a custom ArrayList-like implementation (unsing arrays of course) which can grow if needed, and is faster and more type-safe than an ArrayList, for a particular data type. E.g. if you've got a lot of ints to store, better to store them with an int[] array, rather than ArrayList's Object[] array, which also requires you to use a bunch of annoying wrapper objects. However, writing your own code to do this takes time, and unless you really know what you're doing, it will probably not be as good as ArrayList.
Advantages of Collections: it's easy to switch implementations later. You can easily replace an ArrayList with a LinkedList if you later realize that you need to to do a lot of insert/delete anywhere other than at the end of the structure. Or vice versa, if you realize that fast random access is more important than insert/delete. You can also take advantage of Collections methods to, say, create a read-only view of a collection (assuming the contained objcts are themselves immutable) or create a synchronized view of the collection (though this may well breed a false sense of security when thinking about thread safety). There are a number of other methods available in Collections but not Arrays. which can make some tasks much simpler for you - shuffle(), reverse(), min(), max(). I would argue that if you're not sure which data structure is most appropriate for your problem, using some sort of Colelction is usually the safest bet.
[ April 08, 2003: Message edited by: Jim Yingst ]

Thanks for catching sort being wrong. And I get so fried with Java not allowing primitives in collections. It is such a pain to store a map of ints. Sheesh.

Check out Primitive Collections for Java or GNU Trove4J. And, on a tangent because it's got nothing to do with primitives, I really like Jakarta Collections. Closures, predicates, and such simple but necessary things as a way to turn an Enumeration into an Iterator or to filter the results returned by an Iterator. All those things that are missing from the Java Collections framework.
- Peter