Java Collections – Default Capacity Differences

I don't know why you need to keep a list of all instances of a class.

That would cause memory leakage since those objects will never be disposed of, since the list will still be referencing them after no other class does.

But if you really want to follow that route:

1. Use the Factory pattern. A factory class with methods that instanciate the class and return the objects. That way you have a centralize point to control the instantiations.
2. Use the Singleton pattern to hold a list or lists that hold the instances.
3. Make the factory put each object of a certain type in a list after creating them.

By the way: constructors are inherited.

Although it is correct from a narrowly technical point of view to say that Set implements Iterable, but SortedMap does not, it is not a very useful question to ask. A more useful question to ask is whether both classes offer the Iterable interface, and they certainly both do.

As you know, there are three ways to offer an interface:

1. By explicitly implementing it using the implements keyword.
2. By implementing an interface which extends the interface in question.
3. By exposing a function which returns the interface in question.

Set is declared as follows: public interface Set<E> extends Collection<E> {... so, as you can see, Set does not directly implement Iterable, it only implements it indirectly, by virtue of implementing Collection, which extends Iterable.

Now, SortedMap would also be implementing Iterable indirectly, just as Set does, if it was implementing Collection, but it does not even do that. Instead, it exposes an entrySet() function, which returns a Collection, which extends Iterable.

So, you can have your much desired Iterable in both cases.

If you would like to insist on the narrowly technical question of why Set (indirectly) implements Iterable, but SortedMap offers it via a function instead, the answer is that the designers of the java language runtime made the decision a long time ago to refrain from making extensive use of interfaces extending other interfaces. That's why Map<K,V> does not extend Collection<Map.Entry<K,V>>, offering an entrySet() method instead.

They could have done the opposite, and as a matter of fact the designers of the C# language runtime did choose to go the other way, so IDictionary<K,V> extends ICollection<KeyValuePair<K,V>>.

I have experimented with both ways, and I still have not arrived at a conclusive decision as to which one is better. They simply appear to be two different ways of accomplishing the same thing.

The implementation of Iterator does not imply a stable ordering, as you seem to understand (and therefore it is not clear to me where your question is in that respect.) You may iterate over an unsorted map, in which case nobody can tell what the order of the items will be, and you may insert an element to the map and re-iterate, in which case the order of the items may be completely different from the previous time. (Not just different by one item: all items may appear to be re-arranged.)

There is no need for an OrderedIterable interface because its signature would be identical to Iterable. (And don't get me started on the choice of the java people to introduce a Set besides Collection.) You can just invoke OrderedMap.entrySet(), which the documentation promises will return an ordered set, which means that the Iterator of that set will always yield items in order.