with Java5 we can write:
Foo[] foos = ...
for (Foo foo : foos)
or just using an Iterable in the for loop. This is very handy.
However you can't write a generic method for iterable like this:
public void bar(Iterable<Foo> foos) { .. }
and calling it with an array since it is not an Iterable:
Foo[] foos = { .. };
bar(foos); // compile time error
I'm wondering about the reasons behind this design decision.
Unfortunately, arrays aren't 'class-enough'. They don't implement the Iterable interface.
Since an array isn't an object in the normal sense, it can't implement the interface.
The reason you can use them in for-each loops is because Sun added in some syntatic sugar for arrays (it's a special case).
Since arrays started out as 'almost objects' with Java 1, it would be far too drastic of a change to make them real objects in Java.
As msaeed comments, arrays can implement interfaces (Cloneable and java.io.Serializable). So why not Iterable? I guess Iterable forces adding an iterator method, and arrays don't implement methods. char[] doesn't even override toString. Anyway, arrays of references should be considered less than ideal - use Lists. As dfa comments, Arrays.asList will do the conversion for you, explicitly.
(Having said that, you can call clone on arrays.)
Arrays ought to support Iterable, they just don't, for the same reason that .NET arrays don't support an interface that allows readonly random access by position (there is no such interface defined as standard). Basically, frameworks often have annoying little gaps in them, which it's not worth anyone's time to fix. It wouldn't matter if we could fix them ourselves in some optimal way, but often we can't.
The array is an Object, but its items might not be. The array might hold a primitive type like int, which Iterable can't cope with. At least that's what I reckon.