--- old/src/java.base/share/classes/java/util/doc-files/coll-designfaq.html 2017-08-18 15:03:15.274993692 -0700 +++ new/src/java.base/share/classes/java/util/doc-files/coll-designfaq.html 2017-08-18 15:03:15.062984419 -0700 @@ -1,7 +1,4 @@ - - - + - - +
It was never our intention that programs should catch these @@ -176,7 +172,7 @@ should only arise as a result of programming errors, in which case, your program will halt due to the uncaught exception.
The Collection interface provides this functionality. We are not providing any public implementations of this interface, as we think @@ -185,7 +181,7 @@ atop AbstractCollection (for example, the Collection returned by Map.values).
While the names of the new collections methods do not adhere to the "Beans naming conventions", we believe that they are @@ -207,10 +203,10 @@ case. Thus, we adopted the "traditional" JDK style rather than the Beans style.
Many Collection implementations (including all of the ones provided by the JDK) will have a public clone method, but it would @@ -224,7 +220,7 @@ this type, and use the addAll method to copy the elements of the original collection into the new one.
This is what is referred to as an "Internal Iterator" in the @@ -235,7 +231,7 @@ this functionality is increased by the fact that it requires a public interface to describe upcalls.
It's easy to implement this functionality atop Iterators, and @@ -244,14 +240,14 @@ weight. It could be added to the Collections class at a later date (implemented atop Iterator), if it's deemed useful.
Because we don't believe in using Enumerations (or Iterators) as "poor man's collections." 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.
Again, this is an instance of an Enumeration serving as a "poor man's collection" and we're trying to discourage that. Note @@ -259,7 +255,7 @@ should have constructors that take a Collection (and create a new Collection with the same elements).
The semantics are unclear, given that the contract for Iterator makes no guarantees about the order of iteration. Note, however, @@ -267,10 +263,10 @@ guarantee the order of the iteration.
People were evenly divided as to whether List suggests linked @@ -285,16 +281,16 @@ import java.awt.*; import java.util.List; // Dictates interpretation of "List"
It was decided that the "set/get" naming convention was strongly enough enshrined in the language that we'd stick with it.
This was by design. We feel that mappings are not collections and collections are not mappings. Thus, it makes little sense for @@ -317,10 +313,10 @@ Lists.
We view the method names for Enumeration as unfortunate. They're very long, and very frequently used. Given that we were adding a @@ -329,7 +325,7 @@ names. Of course we could support the new and old names in Iterator, but it doesn't seem worthwhile.
It can be implemented atop the current Iterators (a similar @@ -338,10 +334,10 @@ that everyone has to implement.
If you examine the goals for our Collections framework (in the @@ -363,7 +359,7 @@ as we can to keep them small and manageable, so that Java continues to be an easy, fun language to learn and to use.
Primarily, resource constraints. If we're going to commit to @@ -390,9 +386,9 @@ facility on top of the public APIs.
-Copyright © 1998, 2017, Oracle and/or its affiliates. 500 Oracle Parkway
+Copyright © 1998, 2017, Oracle and/or its affiliates. 500 Oracle Parkway
Redwood Shores, CA 94065 USA. All rights reserved.