Of the original choices (focusing just on the List/Iterator handling, not other organizational questions), I'd strongly recommend 1. (Except return a List rather tha ArrayList for generality.) The collections framework is generally designed to work with Collection instances (especially List instances) rather than Iterators, up to but not including the point where you actually do the iteration. That is, there are a bunch of potentially useful methods floating around, like
Collections.copy(List, List)
Collections.sort(List)
Collections.unmodifiableList(List)
new ArrayList(Collection)
new TreeSet(Collection)
and many more. If you have a method which returns an Iterator, it's harder to apply any of these other methods to the result. But if you return a List (or Set or whatever interface is more appropriate) you will have easy access to the rest of the collections framework, should hte need arise. The Law of Demeter notwithstanding, any programmer who expects to use an Iterator at all should know how to get that Iterator from a Collection in a single method call. It's easy to convert a Collection to an Iterator; it's more work to go the other way. So keeping the Collection as a Collection as long as possible will maximize the reusability of your code.
To iterate through any Collection:
Calling iterator() immediately before iterating is standard usage; you don't need to do it previously in a separate method. The Iterator isn't useful for anything else anyway, you might as well discard it immediately when you're done, and using a local variable for this makes sense.
Note also that upcoming JDK 1.5 is supposed to have
a new construct for iterating throuch a collection more gracefully:
This new construct is designed to work with any Collection, Iterator, or array. So there's no need to convert to an Iterator before hand; the compiler will handle it for you. This may not help you much right now, butit reenforces the idea that passing around Collections rather than Iterators is standard usage.