The Collection interface provides this functionality. We are extremely sympathetic to the desire for type-safe collections. Unfortunately, this won't happen in the the 1.2 release. We suspect that the collections APIs will be used quite pervasively, often with multiple method calls on a single line of code, so it is important that the names be short. Consider, for example, the Iterator methods.
Similar arguments hold for serializable.
If the client doesn't know the actual type of a Collection, it's much more flexible and less error prone to have the client decide what type of Collection is desired, create an empty Collection of this type, and use the addAll method to copy the elements of the original collection into the new one. It's easy to implement this functionality atop Iterators, and the resulting code may actually look cleaner as the user can inline the predicate. Thus, it's not clear whether this facility pulls its weight. This was occasionally done in prior releases, but now that we have the Collection interface, it is the preferred way to pass around abstract collections of objects. The semantics are unclear, given that the contract for Iterator makes no guarantees about the order of iteration.