Revision: 7678
Author: [email protected]
Date: Fri Mar 5 10:25:36 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7678
Modified:
/wiki/LightweightCollections.wiki
=======================================
--- /wiki/LightweightCollections.wiki Tue Mar 2 11:10:24 2010
+++ /wiki/LightweightCollections.wiki Fri Mar 5 10:25:36 2010
@@ -5,7 +5,7 @@
We've found that the API semantics for the JRE collections classes are not
an ideal match for the constraints of running inside browsers, especially
mobile browsers, for several reasons.
== Background and Motivation ==
-_The JRE collections framework encode assumptions about the relationship
between types, objects, and their implementation making them highly
coupled, even at the top of the hierarchy._ For example, the `Map`
interface has methods such as `values()`, `entrySet()`, `keySet()` that
make very specific guarantees about how the returned objects interact with
the map from which they derive. These sorts of prescribed dependencies
between collection types (e.g. using a `Map` implies the use of `Set` and
`Collection`) and the behavior of collection objects themselves prevent
simple implementations. Repeated attempts to optimize GWT's emulated JRE
collections show a relatively high cost for even minimal usage of JRE
collections because, for example, using a `Map` implies using a `Set` and a
`Collection`.
+_The JRE collections framework encode assumptions about the relationship
between types, objects, and their implementation making them highly
coupled, even at the top of the hierarchy._ For example, the `Map`
interface has methods such as `values()`, `entrySet()`, `keySet()` that
make very specific guarantees about how the returned objects interact with
the map from which they derive. These sorts of prescribed dependencies
between collection types (e.g. using a `Map` implies the use of `Set` and
`Collection`) and the behavior of collection objects themselves prevent
simple implementations. Repeated attempts to optimize GWT's emulated JRE
collections show a relatively high code-size cost for even minimal usage of
JRE collections because, for example, using a `Map` implies using a `Set`
and a `Collection`.
_Too few collection types forces runtime enforcement of behaviors that
could be more efficiently modeled statically._ A common example is a class
`T` that wishes to return a reference an internal list. However, the `List`
interface has mutators (e.g. `add()`) which `T` would not want to make
possible "from the outside." The traditional best practice of calling
`Collections.unmodifiableList()` on the returned list reference requires
the allocation of an extra object (which generates extra GC runs that can
turn pathological in IE) as well extra code that must be generated simply
to implement `throw new UnsupportedOperationException()` when a mutator is
called on the wrapper object. If instead there were an `ImmutableList` type
that the list collections implement, class `T` could simply have returned
an immutable reference, which would ensure attempts to modify the list are
caught at compile-time (i.e. because `ImmutableList` has no mutators) and
which would prevent extra object allocations and potentially even
facilitate inlining at compile time. This
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
