diff -r 5652acd48509 -r 42bc1e89134d emul/compact/src/main/java/java/util/LinkedHashMap.java --- a/emul/compact/src/main/java/java/util/LinkedHashMap.java Mon Feb 25 19:00:08 2013 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,491 +0,0 @@ -/* - * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. Oracle designates this - * particular file as subject to the "Classpath" exception as provided - * by Oracle in the LICENSE file that accompanied this code. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - */ - -package java.util; -import java.io.*; - -/** - *
Hash table and linked list implementation of the Map interface, - * with predictable iteration order. This implementation differs from - * HashMap in that it maintains a doubly-linked list running through - * all of its entries. This linked list defines the iteration ordering, - * which is normally the order in which keys were inserted into the map - * (insertion-order). Note that insertion order is not affected - * if a key is re-inserted into the map. (A key k is - * reinserted into a map m if m.put(k, v) is invoked when - * m.containsKey(k) would return true immediately prior to - * the invocation.) - * - *
This implementation spares its clients from the unspecified, generally - * chaotic ordering provided by {@link HashMap} (and {@link Hashtable}), - * without incurring the increased cost associated with {@link TreeMap}. It - * can be used to produce a copy of a map that has the same order as the - * original, regardless of the original map's implementation: - *
- * void foo(Map m) { - * Map copy = new LinkedHashMap(m); - * ... - * } - *- * This technique is particularly useful if a module takes a map on input, - * copies it, and later returns results whose order is determined by that of - * the copy. (Clients generally appreciate having things returned in the same - * order they were presented.) - * - *
A special {@link #LinkedHashMap(int,float,boolean) constructor} is - * provided to create a linked hash map whose order of iteration is the order - * in which its entries were last accessed, from least-recently accessed to - * most-recently (access-order). This kind of map is well-suited to - * building LRU caches. Invoking the put or get method - * results in an access to the corresponding entry (assuming it exists after - * the invocation completes). The putAll method generates one entry - * access for each mapping in the specified map, in the order that key-value - * mappings are provided by the specified map's entry set iterator. No - * other methods generate entry accesses. In particular, operations on - * collection-views do not affect the order of iteration of the backing - * map. - * - *
The {@link #removeEldestEntry(Map.Entry)} method may be overridden to - * impose a policy for removing stale mappings automatically when new mappings - * are added to the map. - * - *
This class provides all of the optional Map operations, and - * permits null elements. Like HashMap, it provides constant-time - * performance for the basic operations (add, contains and - * remove), assuming the hash function disperses elements - * properly among the buckets. Performance is likely to be just slightly - * below that of HashMap, due to the added expense of maintaining the - * linked list, with one exception: Iteration over the collection-views - * of a LinkedHashMap requires time proportional to the size - * of the map, regardless of its capacity. Iteration over a HashMap - * is likely to be more expensive, requiring time proportional to its - * capacity. - * - *
A linked hash map has two parameters that affect its performance: - * initial capacity and load factor. They are defined precisely - * as for HashMap. Note, however, that the penalty for choosing an - * excessively high value for initial capacity is less severe for this class - * than for HashMap, as iteration times for this class are unaffected - * by capacity. - * - *
Note that this implementation is not synchronized. - * If multiple threads access a linked hash map concurrently, and at least - * one of the threads modifies the map structurally, it must be - * synchronized externally. This is typically accomplished by - * synchronizing on some object that naturally encapsulates the map. - * - * If no such object exists, the map should be "wrapped" using the - * {@link Collections#synchronizedMap Collections.synchronizedMap} - * method. This is best done at creation time, to prevent accidental - * unsynchronized access to the map:
- * Map m = Collections.synchronizedMap(new LinkedHashMap(...));- * - * A structural modification is any operation that adds or deletes one or more - * mappings or, in the case of access-ordered linked hash maps, affects - * iteration order. In insertion-ordered linked hash maps, merely changing - * the value associated with a key that is already contained in the map is not - * a structural modification. In access-ordered linked hash maps, - * merely querying the map with get is a structural - * modification.) - * - *
The iterators returned by the iterator method of the collections - * returned by all of this class's collection view methods are - * fail-fast: if the map is structurally modified at any time after - * the iterator is created, in any way except through the iterator's own - * remove method, the iterator will throw a {@link - * ConcurrentModificationException}. Thus, in the face of concurrent - * modification, the iterator fails quickly and cleanly, rather than risking - * arbitrary, non-deterministic behavior at an undetermined time in the future. - * - *
Note that the fail-fast behavior of an iterator cannot be guaranteed - * as it is, generally speaking, impossible to make any hard guarantees in the - * presence of unsynchronized concurrent modification. Fail-fast iterators - * throw ConcurrentModificationException on a best-effort basis. - * Therefore, it would be wrong to write a program that depended on this - * exception for its correctness: the fail-fast behavior of iterators - * should be used only to detect bugs. - * - *
This class is a member of the
- *
- * Java Collections Framework.
- *
- * @param More formally, if this map contains a mapping from a key
- * {@code k} to a value {@code v} such that {@code (key==null ? k==null :
- * key.equals(k))}, then this method returns {@code v}; otherwise
- * it returns {@code null}. (There can be at most one such mapping.)
- *
- * A return value of {@code null} does not necessarily
- * indicate that the map contains no mapping for the key; it's also
- * possible that the map explicitly maps the key to {@code null}.
- * The {@link #containsKey containsKey} operation may be used to
- * distinguish these two cases.
- */
- public V get(Object key) {
- Entry Sample use: this override will allow the map to grow up to 100
- * entries and then delete the eldest entry each time a new entry is
- * added, maintaining a steady state of 100 entries.
- * This method typically does not modify the map in any way,
- * instead allowing the map to modify itself as directed by its
- * return value. It is permitted for this method to modify
- * the map directly, but if it does so, it must return
- * false (indicating that the map should not attempt any
- * further modification). The effects of returning true
- * after modifying the map from within this method are unspecified.
- *
- * This implementation merely returns false (so that this
- * map acts like a normal map - the eldest element is never removed).
- *
- * @param eldest The least recently inserted entry in the map, or if
- * this is an access-ordered map, the least recently accessed
- * entry. This is the entry that will be removed it this
- * method returns true. If the map was empty prior
- * to the put or putAll invocation resulting
- * in this invocation, this will be the entry that was just
- * inserted; in other words, if the map contains a single
- * entry, the eldest entry is also the newest.
- * @return true if the eldest entry should be removed
- * from the map; false if it should be retained.
- */
- protected boolean removeEldestEntry(Map.Entry
- * private static final int MAX_ENTRIES = 100;
- *
- * protected boolean removeEldestEntry(Map.Entry eldest) {
- * return size() > MAX_ENTRIES;
- * }
- *
- *
- *