Fact-checked by Grok 2 weeks ago

Java collections framework

The Java Collections Framework (JCF) is a unified architecture within the Java Standard Edition (SE) platform for representing and manipulating collections—groups of objects treated as a single unit, such as lists, sets, and maps—enabling developers to store, retrieve, and process data independently of specific implementation details. Introduced in J2SE 1.2 in December 1998 as a replacement for legacy classes like Vector and Hashtable, it has evolved significantly, with major enhancements including generics in Java SE 5 for type safety and lambda expressions in Java SE 8 for functional-style operations on collections. At its core, the framework consists of interfaces that define abstract data types, such as the root Collection interface (encompassing subinterfaces like List for ordered collections allowing duplicates, Set for unique elements, and Queue for FIFO processing) and the Map interface for key-value associations; these interfaces support operations like adding, removing, and iterating over elements, with some methods optional to allow for immutable or read-only views. Implementations provide concrete classes realizing these interfaces, including general-purpose ones like ArrayList (resizable array), HashSet (hash table-based set), and HashMap (hash table-based map), as well as specialized variants for concurrency (e.g., ConcurrentHashMap), sorting (e.g., TreeSet), and legacy compatibility. Additionally, the framework includes algorithms via the Collections utility class, offering polymorphic methods for tasks such as sorting (sort), searching (binarySearch), and synchronization (synchronizedList), which operate on any compatible collection to promote reuse and efficiency. The JCF's design reduces programming effort by supplying ready-to-use, high-performance data structures and algorithms, thereby increasing code speed, quality, and maintainability while fostering interoperability across unrelated APIs and simplifying the for new developers compared to more complex frameworks in languages like C++. It promotes software reuse by allowing collections to be passed as parameters or returned from methods without tying to specific types, and its ongoing updates—such as APIs in SE 8—continue to adapt it for modern paradigms like and .

Overview

Purpose and Benefits

The Java Collections Framework provides a unified architecture within the java.util package for representing and manipulating groups of objects, known as collections, while allowing developers to work independently of specific implementation details. This framework encompasses interfaces, implementations, and algorithms that enable the storage, retrieval, and manipulation of data in a standardized manner. Its primary design goals include reducing programming effort by offering reusable data structures and algorithms, thereby eliminating the need for developers to implement common functionality from scratch; increasing performance through carefully optimized, high-quality implementations; and promoting by enabling different to information seamlessly via a common set of interfaces. These objectives ensure the remains compact in size and conceptual complexity, focusing on core abstractions without overwhelming users with extraneous features. Key benefits of the include high-level from underlying structures, which simplifies and portability across implementations; for generics introduced in JDK 1.5, providing compile-time and reducing the need for explicit casting; built-in algorithms for operations such as and ; and extensibility through abstract classes that allow custom implementations to integrate easily. Historically, the framework addressed inconsistencies in pre-existing classes by retrofitting legacy implementations like Vector and Hashtable to conform to its interfaces, establishing a consistent that encourages migration to modern, non-synchronized options for better performance in non-threaded contexts.

Comparison to Arrays

Java arrays are fixed-size data structures that must be declared with a specific type and length at creation time, accommodating either types or reference types but unable to change size dynamically without manual intervention. To resize an array, developers must create a new of the desired size and copy elements from the original using methods like System.arraycopy, which copies a range of elements from a source to a destination starting at specified offsets. This process is error-prone and inefficient, as it requires explicit handling of the copying operation and potential memory reallocation each time growth is needed. Arrays also lack built-in support for common operations such as iteration, searching, and sorting; iteration typically relies on indexed for-loops, while searching and sorting require utility methods from the java.util.Arrays class. Additionally, while arrays provide compile-time type safety for homogeneous elements (e.g., String[]), they do not support generics, leading to type safety issues when storing heterogeneous elements in an Object[] array, which necessitates explicit casting upon retrieval and risks ClassCastException at runtime. The Java collections framework addresses these limitations by providing dynamic data structures that automatically resize as needed, such as ArrayList, which internally uses arrays but handles growth transparently by allocating larger backing arrays when capacity is exceeded. Collections incorporate type-safe generics (introduced in JDK 1.5), allowing parameterized types like List<String> to enforce compile-time type checking and eliminate most casting for homogeneous collections, while still permitting Object-based storage for heterogeneous needs without the same runtime risks. Furthermore, the framework integrates utility methods for operations like sorting (Collections.sort) and searching (Collections.binarySearch), enabling polymorphic algorithms that work across collection implementations without manual implementation. For illustration, consider declaring and using an versus an ArrayList: Array example: 
java
int[] numbers = new int[3];  // Fixed size of 3
numbers[0] = 1;
numbers[1] = 2;
// To add a fourth element, manually resize:
int[] larger = new int[4];
System.arraycopy(numbers, 0, larger, 0, 3);
larger[3] = 3;
numbers = larger;  // Reference now points to new array
ArrayList example: 
java
List<Integer> numbers = new ArrayList<>();  // Dynamic size
numbers.add(1);
numbers.add(2);
numbers.add(3);  // Automatically resizes if needed
This contrast highlights how collections simplify dynamic while enhancing safety and functionality over raw arrays.

History

Origins in JDK 1.2

Prior to the release of JDK 1.2 in December 1998, provided only a limited and inconsistent set of classes for managing collections of objects, primarily the legacy implementations , (a subclass of ), , and the interface for traversal. These classes, introduced in JDK 1.0 and 1.1, offered basic functionality—such as dynamic arrays via and key-value storage via —but suffered from design flaws, including unnecessary that imposed overhead in single-threaded contexts and a lack of due to the absence of interfaces. Developers often had to create custom wrappers or adapters to use these classes together, leading to error-prone and verbose code. The Collections Framework originated from efforts at to address these shortcomings by creating a standardized, extensible architecture for data structures, with development beginning in 1997. Primarily designed by along with a team of engineers, the framework drew inspiration from established models like the C++ Standard Template Library while prioritizing 's object-oriented principles, such as interface-based design and runtime polymorphism. This work aligned with broader initiatives under the Java Foundation Classes (JFC), which included the Swing GUI toolkit, aiming to enhance the platform's utility for complex applications requiring reusable collection utilities. Upon its standardization and inclusion in JDK 1.2, the framework introduced foundational interfaces—Collection as the root for group representations, for ordered collections, Set for unique elements, and for key-value associations—alongside efficient concrete classes like (an unsynchronized, resizable array implementation), HashSet (a hash table-based set), and HashMap (a hash table-based map). Legacy classes like and Hashtable were retrofitted to implement List and Map, respectively, ensuring backward compatibility while encouraging migration to the new, more flexible components. This debut reduced programming complexity by providing algorithms for common operations like sorting and searching, independent of underlying representations.

Evolution Through Versions

In Java SE 1.4, the Collections Framework received minor enhancements, including the introduction of LinkedHashMap and LinkedHashSet, which maintain insertion order while providing performance comparable to HashMap and HashSet. These classes use a combined with a doubly-linked list to preserve the order of element insertion, enabling applications requiring predictable iteration without additional overhead. Additionally, the Collections utility class gained new methods such as rotate, replaceAll, and sublist indexing operations, along with the RandomAccess marker interface to optimize list implementations for . Java SE 5.0 (JDK 1.5) marked a significant advancement with the adoption of generics via JSR 14, providing compile-time to collections and eliminating the need for explicit in most cases. This update, combined with autoboxing/unboxing and the enhanced for-each loop, simplified collection usage by allowing direct iteration over elements without explicit iterators. Variable arguments (varargs) further eased method calls involving collections, such as passing arrays or lists flexibly. Concurrently, JSR 166 introduced the java.util.concurrent package, adding thread-safe collections like ConcurrentHashMap, CopyOnWriteArrayList, and ConcurrentSkipListSet to support scalable, high-performance multithreaded applications without external synchronization. Subsequent releases through JDK 1.6 and JDK 7 brought targeted improvements without overhauling the core framework. In JDK 1.6, the NavigableSet and NavigableMap interfaces extended SortedSet and SortedMap, respectively, adding navigation methods like lower, floor, ceiling, and higher for efficient nearest-match queries in ordered collections. Implementations such as TreeSet and TreeMap adopted these interfaces, enhancing support for range-based operations. JDK 7, via Project Coin (JSR 334), introduced small language enhancements like the diamond operator (<>) for abbreviated instantiation, which streamlined collection declarations (e.g., List<String> list = new ArrayList<>();), and try-with-resources for better resource management in collection processing, though no new collection interfaces or classes were added. JDK 8 integrated lambda expressions and the Stream API, transforming how developers process collections through functional-style operations like filter, map, and reduce. Collections gained default methods such as stream() and parallelStream() on interfaces like Collection, enabling declarative pipelines for bulk data operations with optional parallelism, while the Collectors class provided utilities to accumulate streams back into collections. These changes emphasized immutability and expressiveness, reducing boilerplate for common tasks like sorting or grouping. In JDK 21, JEP 431 introduced sequenced collections via new interfaces SequencedCollection, SequencedSet, and SequencedMap, standardizing access to first and last elements across ordered collections like List, Deque, and LinkedHashMap. Methods such as getFirst, getLast, addFirst, and reversed provide a uniform API for endpoint operations and reversal, retrofitting existing implementations without breaking changes and addressing long-standing inconsistencies in ordered collection handling.

Architecture

Key Components

The Java Collections Framework is built upon a set of core components that provide a flexible and extensible architecture for handling groups of objects. These components include interfaces that define behavioral contracts, abstract classes that offer partial implementations to ease development, and concrete classes that deliver full-fledged, ready-to-use data structures. This layered design allows developers to choose the appropriate level of abstraction based on their needs, promoting and across different parts of an application. Interfaces serve as the foundational contracts in the framework, specifying the operations that collections must support without dictating how they are implemented. For instance, the Collection interface outlines basic operations such as adding, removing, and checking the size of elements, while more specialized interfaces like List extend it to include ordered access methods. These interfaces enable polymorphism, allowing algorithms and utilities to work with any compatible implementation, independent of the underlying representation. Over a dozen such interfaces exist, covering collections like sets, lists, queues, and maps, forming the primary means by which collections are manipulated. Abstract classes provide skeletal or partial implementations of these interfaces, reducing the effort required to create custom collections by handling common functionality. Classes like AbstractCollection implement the Collection interface by providing default implementations for methods such as iterator() and size(), leaving subclasses to focus on specific behaviors like element storage. Similarly, AbstractList extends this for ordered collections, offering hooks for indexed access. This approach minimizes and ensures consistency across implementations. Concrete classes offer complete, production-ready implementations that can be instantiated directly. Examples include ArrayList, which uses a for efficient , and HashMap, which employs a for fast key-value storage and retrieval. Other notable ones are LinkedList for sequential access, HashSet for unordered unique elements, and TreeMap for sorted key-value pairs. These classes fully adhere to the framework's interfaces, allowing seamless integration with its algorithms and utilities. The core of the framework resides in the java.util package, with concurrent extensions in java.util.concurrent, which developers access through import statements such as import java.util.*; or specific imports like import java.util.List;. This package encapsulates all interfaces, classes, and supporting utilities, ensuring a centralized location for collection-related functionality and avoiding namespace pollution in user code. The framework incorporates several to enhance usability and compatibility. The is evident in the Map interface's collection view operations, such as keySet(), entrySet(), and values(), which provide simplified, collection-like access to map contents without exposing internal complexities. The facilitates integration with legacy code, for example, by wrapping older collection types like Vector or Hashtable to conform to modern interfaces, and is also suggested for extending iterators with additional capabilities like peeking ahead. These patterns contribute to the framework's simplicity and .

Hierarchy of Interfaces

The Java Collections Framework is structured around a hierarchy of interfaces that define the fundamental behaviors and relationships among collection types. At the root of this hierarchy is the Iterable<T> interface, which serves as the top-level abstraction for all collections by providing a method to obtain an , thereby enabling the use of the enhanced for-each loop introduced in Java 5. This interface ensures that every collection can be traversed in a standardized manner without exposing internal details. Extending Iterable<T>, the Collection<E> interface forms the primary root for most collection types, representing a group of objects known as elements and defining core operations such as size(), isEmpty(), contains(Object), and bulk methods like addAll(Collection<?>) and removeAll(Collection<?>). This interface branches into several sub-hierarchies: the List<E> subinterface, which extends Collection<E> to support ordered collections permitting duplicate elements and providing positional access via methods like get(int) and set(int, E); the Set<E> subinterface, which also extends Collection<E> but enforces uniqueness among elements with no guaranteed order; and the Queue<E> subinterface, extending Collection<E> to model collections designed for holding elements prior to processing, typically in a first-in, first-out (FIFO) manner. Further refinements include Deque<E>, which extends Queue<E> (and thus Collection<E>) to allow insertion and removal at both ends; SortedSet<E>, extending Set<E> to maintain elements in a sorted order based on their natural ordering or a comparator; and NavigableSet<E>, which extends SortedSet<E> by adding navigation methods for locating closest matches. In parallel to the Collection hierarchy, the Map<K,V> interface operates independently, not extending Collection or Iterable directly, as it represents an object that maps keys to values rather than a collection of elements. However, it bridges to the collection hierarchy through methods like entrySet(), which returns a Set view of the mappings, and values(), which returns a Collection view of the values, allowing maps to integrate with collection-based operations. Similar sub-hierarchies exist for maps, including SortedMap<K,V> extending Map<K,V> for sorted keys and NavigableMap<K,V> extending SortedMap<K,V> for enhanced navigation. Abstract classes in the framework extend these interfaces to provide partial implementations, facilitating concrete class development without delving into full details here.

Core Collection Interfaces

Collection Interface

The Collection interface serves as the root of the Java Collections Framework hierarchy, defining the core operations for representing and manipulating groups of objects known as elements. It extends the Iterable interface, enabling collections to be traversed using iterators, and provides a foundation for subinterfaces such as List, Set, Queue, and SequencedCollection (added in Java SE 21 for collections with a defined encounter order supporting first, last, and reversed views) that add specialized behaviors. This interface is designed for maximum generality, allowing it to be used when passing collections between methods or manipulating them without assuming a specific type, and it supports both duplicate elements and ordering depending on the implementation. Some collections based on Collection may allow null elements, while others restrict them, potentially throwing NullPointerException or ClassCastException for incompatible types. The interface includes query operations to inspect the collection's state without modifying it. The size() method returns the number of elements, bounded by Integer.MAX_VALUE, while isEmpty() provides a convenient check equivalent to size() == 0. The contains(Object o) method determines if a specified element is present, relying on the equals method of the elements, and containsAll(Collection<?> c) verifies that all elements from another collection are contained within this one. Additionally, equals(Object o) compares two collections for equality based on their elements, and hashCode() generates a hash code consistent with this equality definition; implementations may optimize these to avoid full element comparisons when possible. The toArray() methods convert the collection to an array, either as Object[] or a typed array, returning a newly allocated array that the caller can safely modify. Modification operations allow adding or removing elements, though these are optional and may throw UnsupportedOperationException if not supported by the implementation, such as in unmodifiable views created by Collections.unmodifiableCollection(). The add(E e) method ensures an element is included (adding it if absent), and remove(Object o) eliminates the first occurrence of a matching element. The clear() method removes all elements. Bulk operations extend these for efficiency across multiple elements: addAll(Collection<? extends E> c) incorporates all elements from another collection; removeAll(Collection<?> c) deletes all matching elements; retainAll(Collection<?> c) retains only those matching elements from the specified collection, effectively performing set-like intersection; and removeIf(Predicate<? super E> filter) (added in Java SE 8) removes all elements matching the given predicate. These bulk methods enable concise manipulations, such as filtering or merging collections, and are particularly useful for operations that would otherwise require explicit iteration. As an extension of Iterable<E>, the Collection interface inherits the iterator() method, which returns an Iterator<E> for sequential access to elements, supporting the framework's emphasis on as the primary traversal mechanism. Since Java 8, it also provides stream() and parallelStream() methods to create sequential or parallel streams for functional-style processing. View collections, which delegate operations to a backing collection, implement Collection to reflect changes bidirectionally, ensuring without duplicating data.

Iterable and Iterators

The Iterable interface, introduced in Java 2 Platform, Standard Edition (J2SE) , serves as the foundational mechanism for enabling iteration over collections and other objects in the Java Collections Framework. It defines a single abstract method, Iterator<T> iterator(), which returns an iterator over the elements of type T in the implementing class; since Java SE 8, it also includes default methods forEach(Consumer<? super T> action) to perform an action for each element and Spliterator<T> spliterator() to support parallel traversal. Implementing Iterable allows objects to be used directly in the enhanced for-loop construct, known as the for-each loop, which simplifies traversal without explicit index management; for example, for (T t : iterable) { ... } internally calls iterable.[iterator](/page/Iterator)() to obtain the iterator and iterates until hasNext() returns false. All core collection interfaces, such as Collection, extend Iterable to ensure uniform iterability across the framework. The Iterator<E> interface provides the basic protocol for sequential forward traversal of collections, replacing the older Enumeration from pre-1.2 APIs with improved method names and support for safe removal during iteration. It declares three key methods: boolean hasNext() to check if more elements remain, E next() to retrieve and advance to the next element (throwing NoSuchElementException if none exists), and void remove() to delete the last element returned by next() (optional operation, throwing UnsupportedOperationException if not supported); since Java SE 8, it includes a default method forEachRemaining(Consumer<? super E> action) to apply an action to all remaining elements. Iterators obtained from collections are typically fail-fast, meaning they monitor the collection's structure for concurrent modifications (e.g., additions or removals outside the iterator) by tracking a modification count (modCount); if a mismatch is detected during hasNext() or next(), a ConcurrentModificationException is thrown to prevent unpredictable behavior. This design promotes in single-threaded contexts by failing quickly rather than producing arbitrary results. For ordered collections like lists, the ListIterator<E> extends Iterator<E> to support bidirectional traversal and in-place modifications, enabling more flexible navigation than standard forward-only iteration. It adds methods such as boolean hasPrevious() and E previous() for reverse movement, void add(E e) to insert an element before the current position (shifting subsequent elements), void set(E e) to replace the last returned element, and index-related queries like int nextIndex() and int previousIndex() to determine positions during traversal. These operations maintain the list's integrity, with add() and remove() being mutually exclusive with direct list modifications to avoid exceptions; like basic iterators, ListIterator instances are fail-fast. List implementations provide factory methods like List.listIterator() (optionally starting at a specific index) to obtain these iterators. Introduced in Java SE 8, the Spliterator<T> interface complements Iterator by supporting parallel traversal, particularly for stream processing, through splittable iteration that allows dividing the element source into sub-iterators for concurrent execution. It includes methods like boolean tryAdvance(Consumer<? super T> action) for sequential processing of remaining elements, Spliterator<T> trySplit() to attempt partitioning the source (returning null if unsplittable), and long estimateSize() to provide an approximate count of remaining elements for load balancing in parallel operations. Spliterators also report characteristics (e.g., ORDERED, SIZED, SUBSIZED) via int characteristics() to optimize behavior, such as preserving encounter order or estimating parallelism potential. Collections can produce spliterators via Collection.spliterator(), which often wraps the underlying iterator while inheriting fail-fast properties. The ConcurrentModificationException is a runtime exception specifically thrown by fail-fast iterators and spliterators when they detect structural changes to the underlying collection that occurred outside the iterator's control, such as direct calls to add() or remove() on the collection during iteration. This detection relies on internal counters like modCount in implementations (e.g., ArrayList increments it on mutations), compared against an expected value in the iterator; a discrepancy triggers the exception immediately upon the next iterator operation. While this mechanism does not guarantee detection in all multithreaded scenarios (e.g., due to timing issues), it provides a best-effort safeguard against subtle bugs in single-threaded code, encouraging explicit for concurrent access.

List Collections

List Interface

The interface in the Java Collections Framework defines an ordered collection that extends the Collection and SequencedCollection (since Java 21) interfaces, enabling elements to be accessed, inserted, and removed by their integer indices, similar to arrays but with dynamic sizing. This extension adds support for maintaining the relative order of elements as they are inserted, allowing duplicate elements and, in many cases, null values depending on the specific implementation. are zero-based, meaning the first element is at index 0, and they provide methods for precise positional manipulation without requiring traversal from the beginning. Key methods for positional access include get(int index), which retrieves the element at the specified ; set(int index, E [element](/page/Element)), which replaces the element at the given index and returns the previous one; add(int index, E [element](/page/Element)), which inserts the element at the index, shifting subsequent elements; and remove(int index), which deletes the element at the index and shifts the rest. Additional search methods such as indexOf(Object o) return the lowest of the specified element or -1 if absent, while lastIndexOf(Object o) returns the highest . For iteration, listIterator() provides a bidirectional starting at the beginning, and listIterator(int [index](/page/Index)) starts at a specific , allowing forward and backward traversal with modification capabilities. The subList(int fromIndex, int toIndex) method creates a view of a portion of the list backed by the original, reflecting changes bidirectionally. Since Java 21, SequencedCollection adds methods for endpoint operations, including addFirst(E e), addLast(E e), getFirst(), getLast(), removeFirst(), removeLast(), and reversed(), enabling efficient access and modification at the sequence's beginning and end. Lists inherently preserve the insertion order of elements and permit duplicates, making them suitable for scenarios requiring sequential data storage. Some implementations support efficient via the RandomAccess marker , enabling constant-time index-based operations. Null elements are generally allowed unless specified otherwise by the implementation. Common use cases for the interface include representing dynamic sequences akin to resizable arrays, where elements can grow or shrink as needed. It also serves as a foundation for more specialized structures, such as stacks (last-in, first-out) or queues (first-in, first-out), through subclassing or additional interfaces.

List Implementations

ArrayList is a resizable-array implementation of the interface that implements all optional list operations and permits all elements, including null. It uses an internal to store elements, with a default initial of 10. When the array's is exceeded during addition, it grows automatically; the growth factor is 1.5 times the current , ensuring amortized constant-time insertion at the end. Random via get and set operations is O(1), while insertions or deletions in the middle require shifting elements, resulting in time . For example, an ArrayList can be initialized with a specific to optimize and avoid frequent resizing: List<String> list = new ArrayList<>(20);. LinkedList provides a doubly-linked list implementation of the interface, supporting all optional operations and allowing null elements. Each element is stored in a node with references to the previous and next nodes, enabling efficient insertions and deletions at both ends in O(1) time. However, random access by index is O(n) because it requires traversing the list from the nearer end. It also implements the and Deque interfaces. Vector is a legacy synchronized growable array implementation of the interface, similar to ArrayList but with thread-safe methods. Like ArrayList, it uses an internal array with a default initial capacity of 10, but it maintains a capacityIncrement parameter that determines growth: when full, it increases by this increment or doubles the capacity if the increment is zero or negative. It includes legacy methods such as elements(), which returns an for iterating over components, differing from the fail-fast iterators in modern collections. In performance comparisons, excels for scenarios with frequent and additions at the end due to its O(1) get operations and amortized O(1) appends, while is preferable for frequent insertions or deletions at arbitrary positions because of its O(1) modifications without shifting. Both are unsynchronized by default, but 's adds overhead, making it less efficient in single-threaded contexts compared to .

Set Collections

Set Interface

The Set interface in the Java Collections Framework defines a collection that cannot contain duplicate elements, modeling the mathematical abstraction of a set where each element is unique based on the equals method. It extends the Collection interface, inheriting all its methods while imposing the additional contract that adding an element already present in the set has no effect and returns false. This ensures that sets maintain uniqueness, with at most one occurrence of any object, including support for a single null element if permitted by the implementation. The Set interface provides no methods beyond those inherited from Collection, such as size(), isEmpty(), add(E e), remove(Object o), contains(Object o), and iterator(), but enforces the prohibition of duplicates across all operations. Unlike lists, sets do not support indexed access or positional insertion, focusing instead on element presence rather than sequence. General-purpose sets make no guarantees regarding the order of elements, though certain subinterfaces may impose ordering. Constructors for sets must reject duplicates to uphold this . For two Set instances to be considered equal via the equals(Object o) , they must have the same size and contain precisely the same elements, irrespective of order or iteration sequence. The hashCode() must return a value consistent with this contract, specifically the sum of the hash codes of all elements in the set, ensuring that equal sets produce equal hash codes. Elements within a set must not be modified in ways that alter their equals comparison while present, as this could violate the set's integrity. Some set implementations may throw exceptions like NullPointerException or ClassCastException for incompatible elements, including nulls. Sets are commonly used for membership testing via contains, efficient deduplication of elements from other collections (e.g., constructing a new set from an existing collection), and representing mathematical sets in applications like distinct value tracking or / operations. Subinterfaces such as extend these capabilities with ordering guarantees for sorted uniqueness.

Set Implementations

The primary non-sorted implementations of the Set interface in the Java Collections Framework are HashSet, LinkedHashSet, and EnumSet, each designed for efficient storage and retrieval of unique elements without duplicates. These classes provide constant-time average-case performance for fundamental operations like add, remove, and contains, leveraging hashing mechanisms tailored to different use cases. HashSet serves as the general-purpose implementation, while LinkedHashSet extends it to preserve insertion order, and EnumSet offers specialized optimization for enum-based elements. Additionally, sets based on IdentityHashMap enable reference-equality comparisons for scenarios requiring identity-based uniqueness. HashSet<E> is a hash table-based implementation of the Set interface, internally backed by a HashMap instance where elements serve as keys and dummy values are used to simulate set behavior. This design ensures no duplicate elements are stored, as HashMap inherently rejects duplicate keys based on the equals method and hash code. The class provides constant-time O(1) average performance for basic operations, assuming a well-distributed hash function that minimizes collisions. By default, HashSet initializes with a capacity of 16 and a load factor of 0.75, meaning the internal hash table resizes (doubling in capacity) when the number of elements exceeds 75% of the capacity to maintain efficiency. Constructors allow customization of initial capacity and load factor to optimize for expected set sizes and reduce rehashing overhead. For example, creating a HashSet and adding elements demonstrates its usage: 
java
import java.util.HashSet;
import java.util.Set;

Set<String> set = new [HashSet<>](/page/Hash)();
set.add("apple");
set.add("banana");
set.add("apple");  // Duplicate ignored
System.out.println(set.size());  // Outputs: 2
over a HashSet does not guarantee any specific order, making it unsuitable for applications requiring predictable traversal. LinkedHashSet<E> extends HashSet by incorporating a doubly-linked list to maintain the insertion order of elements during , while still providing the same hash table-based performance characteristics. This linked structure runs in constant time for insertions at the end and removals, with overall O(1) average time for set operations. Like HashSet, it uses an internal LinkedHashMap for storage, where the map's entry order is preserved. A constructor parameter enables access-order mode, which reorders elements based on their last access (useful for LRU caches), but by default, it follows insertion order. The initial capacity and load factor defaults match those of HashSet (16 and 0.75, respectively), and performance remains comparable, with the added overhead of link maintenance being negligible for most workloads. This makes LinkedHashSet ideal when order matters without the logarithmic costs of sorted alternatives. For instance: 
java
import java.util.LinkedHashSet;
import java.util.Set;

Set<String> set = new LinkedHashSet<>();
set.add("apple");
set.add("banana");
set.add("cherry");
System.out.println(set);  // Outputs: [apple, banana, cherry]
The class ensures that iteration reflects the order in which elements were first inserted, even after removals and re-insertions of duplicates. EnumSet<E> is an abstract, specialized implementation of Set optimized exclusively for enum types, representing elements as bits in a compact bit vector for extremely efficient storage and manipulation. All elements must belong to a single enum type, specified explicitly or implicitly at creation, enabling operations like union, intersection, and complement via static factory methods such as allOf, noneOf, of, and range. This bit-vector approach allows for O(1) time complexity for most operations, including additions and checks, far surpassing general-purpose sets for enum-heavy scenarios due to its minimal memory footprint (e.g., a single long for up to 64 elements). Internally, EnumSet uses two concrete package-private subclasses: RegularEnumSet for enums with 64 or fewer constants, which fits into a single 64-bit integer, and JumboEnumSet for larger enums, employing an array of longs. Iteration follows the natural declaration order of the enum constants. Example usage includes: 
java
import java.util.EnumSet;

enum Day { MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY }

EnumSet<Day> weekdays = EnumSet.of(Day.MONDAY, Day.TUESDAY, Day.WEDNESDAY);
EnumSet<Day> weekend = EnumSet.complementOf(weekdays);
System.out.println(weekend);  // Outputs: [THURSDAY, FRIDAY, SATURDAY, SUNDAY]
EnumSet does not permit null elements and throws NullPointerException if attempted, ensuring and performance. Its design prioritizes speed and space efficiency for fixed, small universes of enum values. For cases requiring reference-equality (==) instead of value-equality (equals), developers can derive a set from an IdentityHashMap<K, Boolean>, using the map's keySet() method to obtain a Set view where uniqueness is determined by object identity rather than content. This approach is useful in graph traversal or serialization contexts where distinct object instances must be tracked separately, even if logically equivalent. The resulting set inherits the O(1) average performance of IdentityHashMap, which uses a hash table with reference-equality comparisons, but it alternates hash codes between table sizes to reduce collisions. However, this is not a standalone class and requires manual construction, such as new IdentityHashMap<>().keySet(). In terms of performance guidance, HashSet is recommended for general-purpose unordered sets due to its simplicity and efficiency, while LinkedHashSet is preferred when insertion or access order is needed, incurring only minor additional cost. EnumSet excels in enum-specific applications, offering superior speed and compactness compared to HashSet for such domains. All these implementations assume proper hash code distribution to achieve optimal O(1) behavior; poor hashing can degrade to O(n) worst-case performance through collisions.

Queue and Deque Collections

Queue and Deque Interfaces

The Queue interface in Java, defined in the java.util package, extends the Collection interface and represents a collection designed for holding elements prior to processing, typically following a first-in, first-out () order where elements are added at the tail and removed from the head. It provides additional operations for insertion, extraction, and inspection beyond those in Collection, supporting both unbounded queues with no fixed capacity and bounded queues that may reject insertions when full. While most implementations enforce semantics, some variations like priority queues order elements by a comparator or natural ordering instead. Key methods in the Queue interface distinguish between operations that throw exceptions on failure and those that return special values, allowing flexible handling in different scenarios. The offer(E e) method inserts an element at the tail and returns true if successful or false if the queue is bounded and full, contrasting with add(E e) which throws an IllegalStateException on capacity violation. For removal and inspection, poll() retrieves and removes the head, returning null if the queue is empty, while remove() does the same but throws a NoSuchElementException if empty; similarly, peek() inspects the head without removal and returns null on emptiness, unlike element() which throws the exception. These dual-method patterns enable non-blocking, predictable behavior in bounded contexts. Most implementations of the Queue interface do not permit null elements (throwing NullPointerException on insertion attempts), as null serves as a sentinel value for empty-queue conditions in methods like poll() and peek(). However, some, such as LinkedList, allow them. The Deque interface, also in java.util, extends Queue and, since Java 21, SequencedCollection, enabling bidirectional access to elements at both ends of the collection, functioning as a double-ended queue (pronounced "deck"). Like Queue, it supports unbounded implementations without fixed limits, though capacity-restricted deques are permitted, and it maintains linear ordering with operations optimized for endpoints rather than random access. When used as a queue, it adheres to FIFO by adding to the tail (addLast or offerLast) and removing from the head (removeFirst or pollFirst); as a stack, it supports LIFO via head operations like push (equivalent to addFirst) and pop (equivalent to removeFirst). Deque provides symmetric methods for both ends, including exception-throwing variants and special-value-returning ones for robustness in bounded scenarios. Insertion methods include addFirst(E e) and addLast(E e), which throw IllegalStateException if full, while offerFirst(E e) and offerLast(E e) return boolean success indicators; removal methods like removeFirst() and removeLast() throw NoSuchElementException if empty, whereas pollFirst() and pollLast() return null. Inspection counterparts such as getFirst(), getLast(), peekFirst(), and peekLast() follow similar patterns. Additionally, push(E e) inserts at the front for stack-like usage, and pop() removes from the front. Similar to , Deque discourages null elements, treating null as a return value for empty conditions in polling and peeking methods, with insertions of null generally throwing NullPointerException. Blocking variants of these interfaces, such as BlockingQueue and BlockingDeque in the java.util.concurrent package, extend the non-blocking behaviors by adding methods that wait for space or elements under contention, but their full details are covered in concurrent collections. Queues are commonly used for task scheduling and , where ordering ensures fair processing of pending jobs. Deques excel in scenarios requiring stacks, such as undo mechanisms, or sliding window algorithms for maintaining a fixed-size of recent elements.

Queue and Deque Implementations

The Java Collections Framework provides several non-blocking implementations for the Queue and Deque interfaces, each optimized for specific use cases involving ordering, priority-based retrieval, or double-ended operations. These classes are designed for single-threaded environments and focus on efficiency in insertion, removal, and access at the queue ends without overhead. Among them, PriorityQueue offers priority-based ordering, while ArrayDeque and LinkedList support double-ended manipulations suitable for queues or stacks. PriorityQueue is an unbounded priority queue that maintains elements in a heap data structure, ensuring the least (or greatest) element is always at the head according to natural ordering or a provided Comparator. Insertion via offer(E) and removal via poll() both operate in O(log n) time due to heap adjustments, making it suitable for scenarios requiring frequent priority-based extractions, such as task scheduling. The implementation does not guarantee stable ordering for equal elements, meaning their relative insertion order may not be preserved upon retrieval. It permits null elements only if the Comparator handles them appropriately, and iteration does not follow priority order. ArrayDeque serves as a resizable-array of the Deque , utilizing a to enable efficient insertions and removals at both ends without capacity restrictions; it automatically grows as needed to accommodate elements. Operations like addFirst(E), addLast(E), removeFirst(), and removeLast() achieve amortized O(1) , outperforming linked structures for end-focused access patterns. Unlike some legacy options, it does not support elements and lacks indexed access, prioritizing speed over random element retrieval. This makes ArrayDeque ideal for implementing queues, deques, or stacks in performance-critical applications. LinkedList implements the Deque interface alongside , leveraging a doubly-linked structure to support O(1) insertions and removals at both ends, which aligns well with semantics when used via methods like offer(E), poll(), and addAll(Collection<? extends E>). As detailed in the Implementations section, its linked nature facilitates efficient end operations but incurs higher memory overhead compared to array-based alternatives. It accepts null elements and provides full functionality, though for pure deque usage, it is generally less efficient than ArrayDeque for frequent end manipulations due to pointer traversal costs. In terms of performance trade-offs, ArrayDeque is recommended over the legacy Stack class for LIFO operations, as it provides faster, non-synchronized push and pop equivalents via addFirst and removeFirst, avoiding the vector-based overhead of Stack. PriorityQueue excels in priority-driven workloads but at the cost of logarithmic operations, whereas ArrayDeque and LinkedList offer constant-time end access for general-purpose queues, with ArrayDeque preferred for its lower and speed in most deque scenarios.

Map Collections

Map Interface

The Map interface in Java's Collections Framework defines an object that maps keys to values, modeling an associative array or dictionary where each key is associated with at most one value. Unlike the Collection interfaces, Map is not part of the collection-view hierarchy but provides its own set of operations for key-value associations. A fundamental characteristic is that it does not allow duplicate keys; if an attempt is made to insert a duplicate key, the existing value is replaced. The handling of null keys and values is implementation-dependent, with some implementations permitting them while others do not. Core methods of the Map interface support basic key-value operations. The put(K key, V value) method associates the specified value with the specified key, returning the previous value if the key already existed or null otherwise. The get(Object key) method retrieves the value associated with the key or null if the key is not present. Presence checks are provided by containsKey(Object key), which returns true if the map contains a mapping for the key, and containsValue(Object value), which checks for the value across all mappings. The remove(Object key) method deletes the mapping for the key and returns the associated value, or null if none existed. Structural information is available via size(), which returns the number of key-value mappings (bounded by Integer.MAX_VALUE), and isEmpty(), which checks if the map has no mappings. The interface includes a nested inner interface Entry<K, V>, which represents a single key-value mapping within the map. Instances of Entry provide access to the key via getKey() and the value via getValue(), both returning null if the entry is removed from the map. The setValue(V value) method updates the value for the entry, returning the previous value. Entries also implement equals(Object) and hashCode() to enable comparison and hashing based on the key-value pair. To facilitate iteration and manipulation, the [Map](/page/Map) interface offers three "collection views" of its contents. The keySet() method returns a Set<K> view of the keys in the map, providing a set-based interface for key operations. The values() method returns a Collection<V> view of the values, which may contain duplicates since multiple keys can map to the same value. The entrySet() method returns a Set<Map.Entry<K, V>> view of the key-value associations, ideal for iterating over all mappings while preserving the pairing. Changes to the map are reflected in these views and vice versa, ensuring consistency. Equality for Map instances is determined by content: two maps are equal if they represent the same key-value mappings, specifically if the entrySet() of one equals that of the other using the Set.equals method. This behavior ensures that maps can be compared regardless of their specific implementations, as long as they adhere to the interface contract. The interface is commonly used for applications requiring fast key-based lookups, such as implementing dictionaries for word translations, caches for temporary , or configuration stores mapping property names to values. These use cases leverage the interface's efficient association and retrieval semantics to model real-world relationships where unique identifiers (keys) point to associated data (values).

Map Implementations

The Java Collections Framework provides several non-sorted, non-concurrent implementations of the interface, each designed for specific use cases involving key-value storage with efficient retrieval. These classes utilize tables as their core data structure, enabling average O(1) for fundamental operations like get and put, though actual performance depends on hash distribution and load factors. HashMap<K,V> is the primary general-purpose implementation, employing an array of buckets where entries are placed based on the hash code of the . Collisions are handled via linked lists in buckets, but since 8, these lists convert to balanced red-black trees when exceeding a threshold (typically 8 entries) to improve worst-case performance from O(n) to O(log n) for lookups in degenerate cases. It permits one and multiple null values, uses a default load factor of 0.75 to balance memory usage and rehashing frequency, and automatically resizes by doubling the bucket array when the threshold is met. This makes HashMap ideal for scenarios prioritizing speed over ordering, such as unordered key-value caches. LinkedHashMap<K,V> extends HashMap by incorporating a doubly-linked list to maintain insertion order by default, allowing predictable over entries in the order they were added. A constructor enables access-order , where recently accessed entries move to the end of the list, facilitating least-recently-used (LRU) eviction policies through the overridable removeEldestEntry method. Like HashMap, it supports keys and values and offers similar O(1) average performance, though the additional linking incurs a minor overhead, making it suitable for applications needing order preservation without full sorting, such as history tracking or ordered caches. Hashtable<K,V>, a legacy class dating to Java 1.0 and retrofitted to the Map interface in Java 2, provides synchronized access for thread safety, wrapping operations with inherent locking. Unlike modern maps, it forbids null keys or values, throwing NullPointerException on insertion attempts. It provides legacy Enumeration methods for iterating keys and values, which are not fail-fast, in addition to the standard Map collection views that use fail-fast iterators. Its performance is comparable to HashMap in single-threaded contexts but suffers from blocking synchronization overhead in multi-threaded use, positioning it as a historical artifact rarely recommended over unsynchronized alternatives or concurrent implementations. WeakHashMap<K,V> specializes in memory-sensitive mappings by storing keys as WeakReference objects, enabling the garbage collector to reclaim entries when keys lack strong references elsewhere. This results in automatic, unpredictable removal of entries, with the map's size potentially shrinking during cycles, and it supports keys and values. With O(1) average operations and a default load factor of 0.75, it is tailored for auxiliary data structures like caches or registries where temporary associations to garbage-collectible objects are needed, preventing memory leaks from orphaned keys. IdentityHashMap<K,V> is a special-purpose implementation that uses reference equality (==) instead of the equals method to compare keys, employing the identity hash code (System.identityHashCode) for hashing. It uses a standard hash table structure similar to HashMap, permits null keys and values, and provides average O(1) operations. This makes it suitable for applications where distinct object instances must be treated as different keys, such as in object graphs, , or annotation processors. However, its use of identity hashing can lead to poorer performance if many objects share hash codes. EnumMap<K extends Enum,V> is a specialized implementation optimized for cases where keys are enum constants, using a dedicated for storage rather than a , resulting in highly efficient O(1) operations without hashing overhead. It does not allow keys (as enums cannot be ) but permits null values, and follows the enum declaration order. EnumMap is compact in and ideal for mappings involving small, fixed sets of enum keys, such as state machines or flags tied to enumerated types. In terms of performance, HashMap excels in raw speed for unordered access, while LinkedHashMap trades minimal efficiency for order maintenance; Hashtable's makes it slower for non-concurrent needs, and WeakHashMap matches HashMap's speed but with GC-induced variability. IdentityHashMap performs similarly to HashMap but may degrade with hash collisions, and EnumMap offers superior efficiency for its specialized use case. For sorted mappings, implementations like TreeMap are covered separately.

Sorted and Navigable Collections

Sorted Interfaces

The sorted interfaces in the Java Collections Framework provide mechanisms for maintaining elements or keys in a total ordering, either through the natural ordering of elements (via the Comparable interface) or a custom Comparator. These interfaces extend the fundamental Set and Map interfaces to enforce sorted order, ensuring that iterations and views reflect this ordering. They are essential for scenarios requiring ordered access to unique elements or key-value pairs without duplicates, such as maintaining a dictionary of words or a timeline of events. The SortedSet<E> interface extends Set<E> and SequencedSet<E> to represent a set of unique elements maintained in ascending order. While it inherits sequenced access methods from SequencedSet<E> (such as getFirst() and removeFirst()), methods like addFirst(E) and addLast(E) throw UnsupportedOperationException because explicit positioning at endpoints contradicts the enforced ordering. Elements must be mutually comparable, either by implementing Comparable or by being accepted by the set's comparator; otherwise, a ClassCastException may occur during insertion. The ordering is consistent with the equals method to preserve the set's contract. Key methods include first(), which returns the lowest element, and last(), which returns the highest element (both throwing NoSuchElementException if the set is empty). The comparator() method returns the comparator used for ordering or null if natural ordering is applied. SortedSet also provides range view methods that return subsets as views backed by the original set, meaning modifications to the view affect the original and vice versa. These views maintain the sorted order: headSet(E toElement) returns elements strictly less than toElement; tailSet(E fromElement) returns elements greater than or equal to fromElement; and subSet(E fromElement, E toElement) returns elements from fromElement (inclusive) to toElement (exclusive), forming a half-open range. Iterators from these views traverse elements in ascending order, and arrays produced by toArray reflect this sorted sequence. A navigable predecessor can be obtained, for example, via headSet(o).last() for an element before o. The NavigableSet<E> interface extends SortedSet<E> to add navigation methods for finding the closest matches to a target element. Key methods include lower(E e) (greatest element strictly less than e), floor(E e) (greatest element less than or equal to e), ceiling(E e) (smallest element greater than or equal to e), and higher(E e) (smallest element strictly greater than e), all returning null if no such element exists. It also provides pollFirst() and pollLast() to retrieve and remove the lowest and highest elements, respectively. For reverse-order access, descendingSet() returns a NavigableSet view in descending order, backed by the original, and descendingIterator() offers reverse iteration. Range views like subSet(E fromElement, boolean fromInclusive, E toElement, boolean toInclusive) allow specifying inclusive/exclusive bounds. These features enable efficient nearest-neighbor searches and bidirectional traversal without additional data structures. Similarly, the SortedMap<K,V> interface extends Map<K,V> to order entries by their keys in ascending sequence, using either natural key ordering or a provided . Keys must be comparable, or a ClassCastException is thrown on insertion. The interface's collection views—entrySet(), keySet(), and values()—are sorted by key order and backed by the map, ensuring bidirectional synchronization of changes. Methods like firstKey() and lastKey() retrieve the lowest and highest keys, respectively, with NoSuchElementException for empty maps. The comparator() method indicates the ordering mechanism. Range operations in SortedMap mirror those in SortedSet but apply to keys: headMap(K toKey) yields a view of keys less than toKey (exclusive); tailMap(K fromKey) for keys greater than or equal to fromKey; and subMap(K fromKey, K toKey) for the inclusive-exclusive range on keys. These views remain backed and sorted, with ordered traversal in their iterators and arrays. The NavigableMap<K,V> interface extends SortedMap<K,V> with navigation capabilities analogous to NavigableSet. It includes lowerEntry(K key), floorEntry(K key), ceilingEntry(K key), and higherEntry(K key) to find the greatest/least entry less than or equal to/greater than the key, returning null if absent. pollFirstEntry() and pollLastEntry() remove and return the lowest/highest entries. Reverse views are provided by descendingMap() (a NavigableMap in descending key order) and descendingKeySet() (a reverse NavigableSet of keys). Enhanced submap methods like subMap(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive) support flexible bounds. These allow precise key-based searches and ordered traversal in both directions. Ordering in both SortedSet and SortedMap relies on the Comparator<T> , which defines a function for establishing among objects. The core compare(T o1, T o2) method returns a negative integer if o1 precedes o2, zero if they are , and a positive integer if o1 follows o2. This must satisfy antisymmetry (signum(compare(x, y)) == -signum(compare(y, x))), , and consistency with equivalence for equal comparisons. Null handling and type compatibility are implementation-dependent, potentially throwing NullPointerException or ClassCastException. These interfaces are used for applications needing ordered unique elements, such as tracking sorted inventory items without duplicates, or ordered key-value mappings like a phone book sorted by last name. For instance, a SortedSet of strings can efficiently retrieve words in a lexical range, while a SortedMap supports quick lookups of values by ordered keys, such as timestamps. The backed views enable efficient range queries and modifications without copying data. Navigable extensions further enhance this for scenarios requiring nearest-match lookups, like features or event timelines.

Sorted Implementations

The TreeSet<E> class implements the NavigableSet<E> interface and provides a sorted set backed by a TreeMap instance, ensuring that elements are maintained in ascending order according to their natural ordering or a specified Comparator. It uses a red-black tree data structure internally to balance the tree and guarantee logarithmic time complexity for core operations such as add, remove, and contains, each performing in O(log n) time where n is the number of elements in the set. The class supports customization via a Comparator provided at construction, allowing reverse or alternative ordering; for instance, new TreeSet<>(Comparator.reverseOrder()) creates a set that sorts elements in descending order. Null elements are not permitted, and attempting to add one results in a NullPointerException, unless the natural ordering or comparator explicitly allows nulls, which is rare in practice. Similarly, the TreeMap<K,V> class serves as the primary sorted map implementation, extending AbstractMap<K,V> and realizing the NavigableMap<K,V> interface through a red-black tree structure that sorts entries by key. Key operations like get, put, containsKey, and remove are designed for O(log n) performance, leveraging the balanced tree to maintain efficiency as the map grows. It offers navigable views such as descendingMap() for reverse-order access and descendingKeySet() for a reverse NavigableSet of keys, both of which reflect changes to the original map. Submap views, created via methods like subMap(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive), provide backed portions of the map restricted to a key range, ensuring that modifications propagate bidirectionally without duplicating data. For concurrent environments, ConcurrentSkipListSet<E> and ConcurrentSkipListMap<K,V> offer scalable, thread-safe alternatives to the above, implementing sorted sets and maps using data structures that maintain ordering by natural key or a provided Comparator. These classes support the same NavigableSet and NavigableMap interfaces but are optimized for high-concurrency scenarios with expected O(log n) operations under contention, though full details on their threading mechanisms appear in the concurrent collections section. The red-black tree foundation in TreeSet and TreeMap ensures balanced structures that deliver consistent logarithmic performance across insertions, deletions, and searches, while enabling in-order iteration for sequential access without additional sorting costs. This makes them suitable for applications requiring ordered storage, such as or range queries, where the overhead of balancing is offset by predictable query times.

Concurrent Collections

Concurrent Interfaces

The concurrent interfaces in the Java collections framework extend the core collection interfaces to support thread-safe operations, enabling multiple threads to access shared data structures without requiring explicit synchronization by the application code. These interfaces are part of the java.util.concurrent package, introduced in 5 to facilitate high-performance concurrent programming, particularly in producer-consumer scenarios and multi-threaded environments where locks can lead to contention. They emphasize atomic operations and blocking behaviors where appropriate, ensuring consistency while minimizing overhead. The BlockingQueue<E> interface extends the Queue<E> interface by adding methods that block until the operation can succeed, making it ideal for coordinating producers and consumers. For instance, the put(E e) method inserts an element at the tail of the queue and blocks if the queue is full, while the take() method retrieves and removes the head element, blocking if the queue is empty. Additionally, remainingCapacity() returns an estimate of the number of additional elements that can be added without blocking, aiding in capacity management. This interface does not permit the use of null elements and is designed to be used only in concurrent contexts. Building on BlockingQueue<E>, the BlockingDeque<E> interface further extends both BlockingQueue<E> and Deque<E> to provide blocking operations at both ends of a , supporting both and LIFO access patterns in a thread-safe manner. It inherits the blocking put and take methods but adds variants such as putFirst(E e) and putLast(E e) for insertion at either end (blocking if full), and takeFirst() and takeLast() for removal (blocking if empty). Like BlockingQueue, it rejects null elements and focuses on bounded, concurrent deque operations. The ConcurrentMap<K, V> interface extends the Map<K, V> interface with atomic methods that perform conditional updates without external locking, promoting high concurrency for key-value stores. Key operations include putIfAbsent(K key, V value), which inserts the value only if the key is absent and returns the previous value (or null); remove(K key, V value), which deletes the mapping only if the key maps to the specified value; and replace(K key, V oldValue, V newValue), which updates the value only if the key maps to oldValue. These methods ensure atomicity, allowing multiple threads to read and write concurrently without intermediate states becoming visible. The interface supports null keys and values only if permitted by the implementation. The TransferQueue<E> interface extends BlockingQueue<E> with methods for direct handoff between producers and consumers, enhancing efficiency in scenarios requiring immediate transfer. Its signature method, transfer(E e), blocks the producer until a receives the element, providing a synchronous alternative to asynchronous queuing. It also includes tryTransfer(E e) for non-blocking attempts and hasWaitingConsumer(), which checks for waiting consumers without blocking. This interface is particularly useful for low-latency, point-to-point communication in concurrent systems and, like its parent, forbids null elements. Overall, these concurrent interfaces exhibit weak guarantees, where iterators may not reflect concurrent modifications and operations do not reads to avoid contention. They are engineered for high concurrency, often employing lock-free techniques or fine-grained locking internally, though the interfaces themselves do not specify implementation details. This design allows for scalable in multi-threaded applications without the need for synchronized wrappers on collections.

Concurrent Implementations

The concurrent implementations in the Java collections framework provide thread-safe data structures optimized for high-concurrency environments, minimizing lock contention through techniques like fine-grained locking, semantics, and lock-free operations. These classes, introduced primarily in Java 5 as part of JSR-166, enable scalable performance in multithreaded applications by allowing multiple threads to access and modify collections simultaneously without external synchronization. ConcurrentHashMap<K,V> is a hash table that supports full concurrency for retrievals and high expected concurrency for updates, achieving average O(1) for operations like get and put. Prior to 8, it used a segment-based design where the table was divided into segments, each protected by its own lock, allowing up to the specified concurrency level (default 16) to update different segments independently. From 8 onward, the implementation shifted to a single using (CAS) operations and synchronized blocks only for treeification or expansion, eliminating segments for better performance under varying loads. The size() method returns an approximate count, as exact sizing would require locking the entire map, potentially harming concurrency. CopyOnWriteArrayList implements a thread-safe variant of ArrayList where mutative operations, such as add, set, and remove, create a fresh copy of the underlying array to ensure immutability of the previous state. This approach makes iterators weakly consistent, providing a snapshot of the array at the time of iterator creation, which remains valid and safe for traversal even during concurrent modifications without throwing ConcurrentModificationException. It supports null elements and is particularly efficient in scenarios where reads vastly outnumber writes, as reads require no locking, though writes incur the cost of array copying proportional to the list size. ArrayBlockingQueue is a bounded blocking backed by a fixed-size , enforcing ordering for elements added via offer or put and removed via poll or take. The capacity is set at and cannot change, making it suitable for buffering in producer-consumer patterns where overflow must be controlled. It uses a single ReentrantLock for all operations but supports an optional fairness parameter in its constructor; when fair=true, blocked threads are granted access in order, though this reduces throughput to prevent . Blocking methods like put block until space is available if full, and take blocks until an element is available if empty. LinkedBlockingQueue provides an optionally bounded blocking queue using a linked list structure, with a default capacity of Integer.MAX_VALUE for unbounded behavior or a specified limit for bounded use. Unlike ArrayBlockingQueue, it employs separate locks—one for put/offer operations at the tail and another for take/poll at the head—allowing producers and consumers to proceed concurrently without mutual exclusion on the entire queue. It maintains FIFO ordering, with the head as the longest-waiting element and the tail for new insertions, and supports blocking semantics similar to ArrayBlockingQueue for full or empty conditions. Null elements are not permitted. ConcurrentSkipListSet offers a scalable concurrent implementation of the NavigableSet interface, based on a ConcurrentSkipListMap, keeping elements sorted according to their natural ordering or a provided . It uses a data structure with probabilistic leveling for nodes, achieving expected average O(log n) time for add, remove, and contains operations through lock-free traversals and minimal contention. This probabilistic balancing ensures amortized efficiency without periodic rebalancing, supporting concurrent insertions and deletions across multiple threads while iterators provide weakly consistent views. Null elements are prohibited. ConcurrentLinkedQueue is an unbounded, non-blocking based on linked nodes, suitable for high-throughput producer-consumer scenarios where blocking is undesirable. It uses lock-free algorithms with operations for add, offer, poll, and peek, ensuring thread-safety without locks and supporting null elements. Iterators are weakly consistent and do not throw ConcurrentModificationException. PriorityBlockingQueue implements a bounded or unbounded blocking that orders elements according to a specified or natural ordering, useful for priority-based task scheduling. It blocks on put if full (for bounded) and on take if empty, using a internally with concurrent access via fine-grained locking. Null elements are not permitted. DelayQueue is an unbounded blocking of Delayed elements, where retrieval is blocked until an element's delay has expired, ideal for scheduling tasks with delays. Elements must implement Delayed, providing getDelay(TimeUnit) and compareTo. It uses a internally and forbids nulls. SynchronousQueue is a blocking queue with zero capacity, where each insert blocks until a retrieves it, facilitating direct handoffs between threads without buffering. It supports both fair and unfair modes via a constructor parameter and rejects nulls, with implementations using either spin-based or blocking mechanisms. These concurrent implementations reduce contention compared to legacy synchronized wrappers like those from Collections.synchronizedList, enabling better scalability in high-thread-count scenarios such as thread pools in applications. For instance, ConcurrentHashMap can handle thousands of concurrent updates with minimal blocking and offers better scalability than fully synchronized maps under heavy load, while CopyOnWriteArrayList excels in read-heavy caches. Blocking queues like ArrayBlockingQueue and LinkedBlockingQueue are commonly used in services for task queuing, with LinkedBlockingQueue preferred for unbounded producer- pipelines due to its dual-lock design. ConcurrentSkipListSet suits concurrent sorted sets in applications requiring ordered access, such as priority queues in concurrent algorithms.

Modern Extensions

Sequenced Collections

Sequenced collections were introduced in Java 21 as part of JEP 431 to provide a standardized way to access and manipulate the endpoints of ordered collections, addressing inconsistencies in the existing framework where operations like getting the first or last element varied across types such as List, Deque, and SortedSet. This enhancement adds new interfaces that extend the core Collection and Map hierarchies, enabling uniform support for endpoint operations and reversal without requiring type-specific casts or custom code. The SequencedCollection<E> interface extends Collection<E> and defines a collection with a well-defined encounter order, supporting operations at both ends and reversibility. It introduces the following key methods:
  • E getFirst(): Returns the first element.
  • E getLast(): Returns the last element.
  • E removeFirst(): Removes and returns the first element.
  • E removeLast(): Removes and returns the last element.
  • void addFirst(E e): Adds the element at the beginning.
  • void addLast(E e): Adds the element at the end.
  • SequencedCollection<E> reversed(): Returns a with reversed order.
These methods allow for efficient bounded access in ordered collections, throwing exceptions like NoSuchElementException if the collection is empty. Building on this, SequencedSet<E> extends both Set<E> and SequencedCollection<E>, providing sequenced operations for sets with unique, ordered elements. It inherits the endpoint methods from SequencedCollection but may throw UnsupportedOperationException for addFirst and addLast in sets where insertion order is not modifiable, such as certain implementations. The reversed() method returns a covariant SequencedSet<E>. This interface is particularly useful for maintaining insertion or access order in unique element collections without duplicating functionality. For maps, SequencedMap<K,V> extends Map<K,V> to support sequenced key sets, value collections, and entry sets, along with endpoint operations on entries. Key methods include:
  • SequencedSet<K> sequencedKeySet(): Returns a sequenced view of keys.
  • SequencedCollection<V> sequencedValues(): Returns a sequenced view of values.
  • SequencedSet<Map.Entry<K,V>> sequencedEntrySet(): Returns a sequenced view of entries.
  • V putFirst(K k, V v): Associates the value with the key at the beginning.
  • V putLast(K k, V v): Associates the value with the key at the end.
  • Map.Entry<K,V> firstEntry(): Returns the first entry.
  • Map.Entry<K,V> lastEntry(): Returns the last entry.
  • Map.Entry<K,V> pollFirstEntry(): Removes and returns the first entry.
  • Map.Entry<K,V> pollLastEntry(): Removes and returns the last entry.
  • SequencedMap<K,V> reversed(): Returns a reversed view.
These enable ordered access in maps like those preserving insertion order. Existing implementations in the Java Collections Framework are retrofitted to support these interfaces via default methods, ensuring . For instance, ArrayList, LinkedList, and Deque implementations conform to SequencedCollection; LinkedHashSet and SortedSet to SequencedSet; and LinkedHashMap and SortedMap to SequencedMap. HashSet gains sequenced support indirectly through LinkedHashSet, which maintains order. Unmodifiable wrappers for sequenced types are also added to Collections for creating read-only views. The primary motivation for sequenced collections is to unify the API for collections with a defined first and last element, such as lists, deques, and ordered sets/maps, reducing boilerplate and improving code readability across the framework. Common use cases include simplifying endpoint access in algorithms processing bounded data, enabling reverse iteration via reversed().stream() without custom iterators, and repositioning elements in ordered sets or maps—such as moving a recently used item to the end in a cache implementation—without type casting or conditional checks.

Other Enhancements

In addition to the sequenced collections introduced in JDK 21, the Java Collections Framework has seen several ancillary enhancements focused on , immutability, , and optimization. These updates, spanning JDK 8 through JDK 21, emphasize and with broader rather than overhauling core interfaces or implementations. One notable usability improvement involves the Collections.addAll method, which leverages varargs to efficiently add multiple elements to a collection in a single operation, offering a streamlined alternative to iterative addition. Introduced with varargs support in Java 5 and refined for performance in subsequent releases including JDK 8, this method internally uses Arrays.asList but executes faster under typical implementations by avoiding unnecessary object creation. For example, Collections.addAll(list, "a", "b", "c") populates the list directly, enhancing code conciseness for initializing collections with variable numbers of elements. JDK 9 introduced convenience factory methods for creating small, immutable collections via static methods on the List, Set, and Map interfaces, as specified in JEP 269. These methods, such as List.of("item1", "item2") and Set.of("unique1", "unique2"), produce compact, unmodifiable instances optimized for up to 10 elements, with varargs overloads for flexibility and Map.ofEntries for key-value pairs. By disallowing nulls and ensuring , these factories promote safer, more readable code while reducing the need for defensive copying in applications handling constants or configuration data. The implementation avoids exposing concrete classes, maintaining encapsulation and supporting concurrent publication without synchronization overhead. The adoption of the (JPMS) in JDK 9 further enhanced the framework by encapsulating its internals within the java.base module, which exports the java.util package to ensure while preventing unauthorized access to implementation details. This modularization, part of JEP 261, improves security and maintainability by allowing developers to define explicit dependencies on collections APIs without relying on classpath visibility, thus reducing risks from internal API misuse in multi-module applications. The java.base module serves as the foundational layer, implicitly required by all others, and its exports for core utilities like collections align with the platform's fidelity to modular boundaries. Performance refinements include string deduplication in the G1 garbage collector, available since JDK 8u20, which shares character arrays among identical String instances to minimize usage. Enabled via -XX:+UseStringDeduplication, this feature particularly benefits collections like HashMap where duplicate string keys are common, potentially reducing by up to 20-30% in string-heavy workloads without altering application code. It operates during garbage collection cycles, identifying and merging duplicates transparently, thus optimizing resource-intensive scenarios such as caching or . From JDK 22 to JDK 25, the Collections Framework has undergone no major structural changes, prioritizing stability and incremental optimizations to support long-term adoption in LTS releases like Java 21 and 25. across these versions highlight enhancements in collection and overall platform performance but confirm the framework's maturity, with focus on reliability for enterprise use cases. Looking toward future-proofing, the integration of virtual threads from Project in JDK 21 enables higher concurrency levels that align seamlessly with the framework's concurrent collections, such as ConcurrentHashMap, by mitigating OS thread overhead and reducing contention in thread-safe operations. This allows applications to scale blocking collection accesses across millions of lightweight threads without performance degradation, preparing the framework for modern, high-throughput workloads.

Utility Classes and Algorithms

Collections Utility Class

The Collections class in the Java Collections Framework provides a set of static utility methods for performing common operations on collections, such as , , and creating wrappers, without requiring instances of the class itself. Introduced in Java 1.2, it contains polymorphic algorithms that operate on sublists, collections, and maps, and it throws NullPointerException for null inputs where applicable. These methods promote code reusability and efficiency by avoiding the need to implement basic manipulations repeatedly. Sorting and searching methods enable efficient ordering and lookup operations on lists. The sort(List<T> list) method sorts the elements in natural order using a stable, linearithmic-time algorithm with O(n log n) average and worst-case complexity, while sort(List<T> list, Comparator<? super T> c) allows custom ordering via a comparator; both may throw ClassCastException if elements are incomparable or UnsupportedOperationException if the list does not support modification. The binarySearch(List<? extends Comparable<? super T>> list, T key) method performs a binary search on a sorted list, returning the index of the key or a negative value indicating the insertion point, with O(log n) time for random-access lists and O(n) for sequential ones; it requires the list to be sorted beforehand and throws ClassCastException for incomparable elements.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#binarySearch(java.util.List, T)) A comparator variant, binarySearch(List<? extends T> list, T key, Comparator<? super T> c), supports custom comparisons.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#binarySearch(java.util.List, T, java.util.Comparator)) Additionally, reverse(List<?> list) reverses the order of elements in linear O(n) time, and shuffle(List<?> list) randomly permutes them using linear time, with optional overloads accepting a Random or RandomGenerator for controlled randomness; both throw UnsupportedOperationException for unmodifiable lists. Unmodifiable views allow creation of read-only collections to prevent accidental modifications, useful for returning defensive copies in APIs. The unmodifiableList(List<? extends T> list) method returns a view that throws UnsupportedOperationException on any mutating operation, preserving the original list's serialization if applicable. Similarly, singletonList(T o) creates an immutable list containing a single element, and emptyList() returns an immutable empty list, both of which are serializable. Synchronization wrappers provide thread-safe views of collections for legacy multithreaded applications, though they require explicit synchronization for compound operations like iteration. The synchronizedList(List<T> list) method wraps a list to make it thread-safe, notifying on structural changes but necessitating manual locking for iterators to avoid concurrent modification issues; it is serializable if the original is. The synchronizedMap(Map<K,V> m) method offers analogous protection for maps, with the same caveats for views and serialization. Other utility methods handle basic queries and comparisons on collections. The min(Collection<? extends T> coll) and max(Collection<? extends T> coll) methods return the minimum or maximum element according to natural ordering in O(n) time, throwing ClassCastException for incomparable elements or NoSuchElementException for empty collections. The frequency(Collection<?> c, Object o) method counts occurrences of an object in O(n) time, throwing NullPointerException if the collection is null.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#frequency(java.util.Collection, java.lang.Object)) Finally, disjoint(Collection<?> c1, Collection<?> c2) returns true if the collections have no elements in common, throwing NullPointerException for null inputs or ClassCastException if types are incompatible.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#disjoint(java.util.Collection, java.util.Collection)) Additional algorithms support list population and filling. The nCopies(int n, T o) method returns an immutable list of n copies of the specified object, throwing IllegalArgumentException if n is negative.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#nCopies(int, T)) The fill(List<? super T> list, T obj) method replaces all elements with the given object, throwing UnsupportedOperationException for unmodifiable lists.[](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#fill(java.util.List, T))

Integration with Other Java Features

The Java Collections Framework integrates seamlessly with the Streams introduced in JDK 8, allowing collections to serve as sources for functional-style data processing pipelines. Every Collection implementation provides default methods stream() and parallelStream(), which return a sequential or potentially parallel Stream backed by the collection's elements, enabling operations like map, filter, and collect without explicit iteration. For instance, a collection can be processed declaratively as in Collection.stream().filter(p -> p > 0).collect(Collectors.toList()), where intermediate operations such as filter apply predicates lazily, and terminal operations like collect trigger evaluation to produce results such as new lists or . This integration leverages the Spliterator interface for efficient traversal, supporting both sequential and parallel execution on multicore systems. Lambdas and the Optional class further enhance collections' expressiveness through functional interfaces added in JDK 8. The forEach(Consumer) method on Collection, inherited from Iterable, accepts a to perform actions on each element, such as collection.forEach(System.out::println), promoting concise iteration without traditional loops. On List implementations, replaceAll(UnaryOperator) applies a to transform every element in place, for example list.replaceAll(x -> x.toUpperCase()) to uppercase strings, throwing exceptions for unmodifiable lists. Streams often return Optional for operations like findFirst(), integrating with lambdas for safe handling of potentially empty results, such as collection.stream().filter(p).findFirst().orElse(defaultValue). Since JDK 9, the modularization of the JDK places the java.util package, including all collections interfaces and implementations, within the foundational java.base module, ensuring automatic accessibility without explicit dependencies in custom modules. Developers creating modules that use collections simply require java.base implicitly, as it forms the core of the platform, allowing seamless import of classes like ArrayList or HashMap in modular applications. Pattern matching enhancements in JDK 21 extend instanceof and switch expressions to work with collections, enabling concise type checks and data extraction. For example, a switch on a collection reference can use patterns like case List<?> l -> processList(l), testing the type and binding variables for further operations, with guarded patterns adding conditions such as case List<?> l when !l.isEmpty(). This feature, finalized in JEP 441, supports exhaustiveness checks for safer code when handling polymorphic collections. Project Loom in JDK 21 introduces virtual threads, which enhance scalability for applications using concurrent collections by allowing millions of lightweight threads without the overhead of traditional platform threads. Virtual threads unmount during blocking operations on concurrent structures like ConcurrentHashMap, freeing carrier threads for other tasks and improving throughput in high-concurrency scenarios. This enables thread-per-request models with concurrent collections, reducing the need for complex async patterns while maintaining low resource usage.

References

  1. [1]
    Lesson: Introduction to Collections (The Java™ Tutorials ...
    This collections Java tutorial describes interfaces, implementations, and algorithms in the Java Collections framework.
  2. [2]
    Storing Data Using the Collections Framework - Dev.java
    Sep 14, 2021 · The Collections Framework was first introduced in Java SE 2, in 1998 and was rewritten twice since then: in Java SE 5 when generics were added; ...<|control11|><|separator|>
  3. [3]
    Collections Framework Overview
    A collections framework is a unified architecture for representing and manipulating collections, enabling collections to be manipulated independently of ...
  4. [4]
    Collections (Java Platform SE 8 ) - Oracle Help Center
    This class consists exclusively of static methods that operate on or return collections. It contains polymorphic algorithms that operate on collections.
  5. [5]
    Java Language Features - JDK for Solaris Developer's Guide
    It adds compile-time type safety to the Collections Framework and eliminates the drudgery of casting. Refer to JSR 14 and to the generics documentation at http ...
  6. [6]
    Hashtable (Java Platform SE 8 )
    ### Summary: Hashtable as a Legacy Class and Relation to Collections Framework
  7. [7]
    Vector (Java Platform SE 8 )
    - **Legacy Class**: Introduced in JDK 1.0, Vector is an older class predating the Java Collections Framework.
  8. [8]
    Arrays - Learning the Java Language
    An array is a container holding a fixed number of values of a single type. Its length is fixed after creation, and elements are accessed by numerical index.Missing: limitations | Show results with:limitations
  9. [9]
    Arrays (Java Platform SE 8 ) - Oracle Help Center
    This class contains various methods for manipulating arrays (such as sorting and searching). This class also contains a static factory that allows arrays to be ...
  10. [10]
    Lesson: Implementations (The Java™ Tutorials > Collections)
    This collections Java tutorial describes interfaces, implementations, and algorithms in the Java Collections framework. ... collections Vector and Hashtable are ...Set Implementations · Map Implementations · List ImplementationsMissing: replacing | Show results with:replacing
  11. [11]
    Collections Framework Change Summary for Java SE 1.4
    This page summarizes the enhancements made to the collections framework in Java SE 1.4. The Collections utility class has several new methods:.Missing: changes JDK
  12. [12]
    Untitled
    It adds compile-time type safety to the Collections Framework and eliminates the drudgery of casting. Refer to JSR 14 and to the generics documentation at http ...
  13. [13]
    New Features and Enhancements
    Support for generics, annotations, enums, and convenience methods has been added. Also, java.lang.Class has been generified. Refer to the documentation at http ...
  14. [14]
    NavigableMap (Java SE 14 & JDK 14) - Oracle Help Center
    This interface is a member of the Java Collections Framework. Since: 1.6 ... Returns a reverse order NavigableSet view of the keys contained in this map.
  15. [15]
    [PDF] The Java® Language Specification - Oracle Help Center
    Jan 21, 1996 · ... support method handle invocation as defined by JSR 292, Dynamically Typed Languages on the Java. Platform. The Java Compatibility Kit (JCK) ...
  16. [16]
    New and Enhanced APIs That Take Advantage of Lambda ...
    In Java SE 8, new classes have been added and existing classes have been enhanced to take advantage of lambda expressions and streams.
  17. [17]
    Collections Framework Enhancements in Java SE 8
    The Java Collections Framework has been updated to support lambda expressions, streams, and aggregate operations.
  18. [18]
    Creating Sequenced Collections, Sets, and Maps - Oracle Help Center
    Beginning with JDK 21, JEP 431 introduces three Java Collections Framework interfaces for creating sequenced collections, sequenced sets, and sequenced maps.<|control11|><|separator|>
  19. [19]
    5 Java Collections Framework - Oracle Help Center
    The Java Collections Framework enables interoperability among unrelated APIs, reduces effort in designing and learning new APIs, and fosters software reuse. The ...
  20. [20]
    Outline of the Collections Framework
    The collections framework consists of: Collection interfaces - The primary means by which collections are manipulated. Collection - A group of objects.
  21. [21]
    Java Collections API Design FAQ
    Quoting from the "Design Goals" Section of the Java Collections Overview: "Our main design goal was to produce an API that was reasonably small, both in size, ...
  22. [22]
    Package java.util - Oracle Help Center
    Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes.
  23. [23]
    java.util (Java SE 21 & JDK 21)
    ### Hierarchy of Interfaces in the Java Collections Framework
  24. [24]
    Collection (Java SE 23 & JDK 23) - Oracle Help Center
    The root interface in the collection hierarchy. A collection represents a group of objects, known as its elements. Some collections allow duplicate elements ...
  25. [25]
    The Collection Interface - Java™ Tutorials
    This collections Java tutorial describes interfaces, implementations, and algorithms in the Java Collections framework.
  26. [26]
    Iterable (Java Platform SE 8 ) - Oracle Help Center
    Performs the given action for each element of the Iterable until all elements have been processed or the action throws an exception.Classes · Iterator · Spliterator · The For-Each Loop
  27. [27]
    Collection (Java Platform SE 8 ) - Oracle Help Center
    A collection represents a group of objects, known as its elements. Some collections allow duplicate elements and others do not. Some are ordered and others ...Collections · Frames · Interface Iterable · Stream
  28. [28]
    Iterator (Java Platform SE 8 ) - Oracle Help Center
    Iterators allow the caller to remove elements from the underlying collection during the iteration with well-defined semantics. Method names have been improved.Classes · ListIterator · PrimitiveIterator
  29. [29]
    ConcurrentModificationException (Java Platform SE 8 )
    This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.
  30. [30]
    ListIterator (Java Platform SE 8 ) - Oracle Help Center
    An iterator for lists that allows the programmer to traverse the list in either direction, modify the list during iteration, and obtain the iterator's current ...
  31. [31]
    List (Java Platform SE 8 ) - Oracle Help Center
    The List interface provides a special iterator, called a ListIterator, that allows element insertion and replacement, and bidirectional access in addition to ...ArrayList · Frames · LinkedList · Uses of Interface java.util.List
  32. [32]
    Spliterator (Java Platform SE 8 ) - Oracle Help Center
    An object for traversing and partitioning elements of a source. The source of elements covered by a Spliterator could be, for example, an array, ...
  33. [33]
    List (Java SE 22 & JDK 22)
    ### Summary of List Interface (java.util.List)
  34. [34]
    The List Interface - Java™ Tutorials
    This collections Java tutorial describes interfaces, implementations, and algorithms in the Java Collections framework.
  35. [35]
    ArrayList (Java Platform SE 8 ) - Oracle Help Center
    In addition to implementing the List interface, this class provides methods to manipulate the size of the array that is used internally to store the list.
  36. [36]
    The Capacity of an ArrayList vs the Size of an Array in Java | Baeldung
    Apr 4, 2025 · The capacity of an ArrayList functions differently to the size of an Array. We explore the differences and when it's a good idea to set an ...
  37. [37]
    LinkedList (Java Platform SE 8 ) - Oracle Help Center
    The list-iterator is fail-fast: if the list is structurally modified at any time after the Iterator is created, in any way except through the list-iterator's ...
  38. [38]
    The Set Interface - Java™ Tutorials
    The Set interface contains only methods inherited from Collection and adds the restriction that duplicate elements are prohibited. Set also adds a stronger ...
  39. [39]
    Set (Java SE 21 & JDK 21)
    ### Summary of Set Interface (Java SE 21)
  40. [40]
    LinkedHashSet (Java SE 21 & JDK 21) - Oracle Help Center
    LinkedHashSet is a Set implementation using a hash table and linked list, maintaining insertion order, and provides constant-time performance for basic ...
  41. [41]
    Set Implementations - Java™ Tutorials
    If you accept the default load factor but want to specify an initial capacity, pick a number that's about twice the size to which you expect the set to grow.
  42. [42]
    Queue (Java SE 21 & JDK 21)
    ### Summary of Queue Interface (Java SE 21)
  43. [43]
    The Queue Interface - Java™ Tutorials
    This collections Java tutorial describes interfaces, implementations, and algorithms in the Java Collections framework.
  44. [44]
    Deque (Java SE 21 & JDK 21)
    ### Summary of Deque Interface
  45. [45]
    The Deque Interface - Java™ Tutorials
    The Deque interface, defines methods to access the elements at both ends of the Deque instance. Methods are provided to insert, remove, and examine the elements ...
  46. [46]
    Queue Implementations - The Java™ Tutorials
    LinkedList implements the Queue interface, providing first in, first out (FIFO) queue operations for add, poll, and so on.
  47. [47]
    Deque Implementations - Java™ Tutorials
    The Deque interface, pronounced as "deck", represents a double-ended queue. The Deque interface can be implemented as various types of Collections.<|separator|>
  48. [48]
    LinkedList (Java SE 21 & JDK 21) - Oracle Help Center
    Returns a list-iterator of the elements in this list (in proper sequence), starting at the specified position in the list. Obeys the general contract of List.
  49. [49]
    Map (Java SE 21 & JDK 21)
    No readable text found in the HTML.<|control11|><|separator|>
  50. [50]
    The Map Interface - Java™ Tutorials
    The Map interface includes methods for basic operations (such as put , get , remove , containsKey , containsValue , size , and empty ), bulk operations (such as ...
  51. [51]
    Map Implementations - Java™ Tutorials
    IdentityHashMap is an identity-based Map implementation based on a hash table. This class is useful for topology-preserving object graph transformations, such ...
  52. [52]
    HashMap (Java SE 21 & JDK 21)
    **Summary of HashMap Implementation Details:**
  53. [53]
    LinkedHashMap (Java SE 21 & JDK 21) - Oracle Help Center
    The LinkedHashMap instance is created with a default load factor (0.75) and an initial capacity sufficient to hold the mappings in the specified map.Missing: LinkedHashSet | Show results with:LinkedHashSet
  54. [54]
    Hashtable (Java SE 21 & JDK 21)
    ### Summary of `Hashtable` from Java SE 21 Documentation
  55. [55]
    WeakHashMap (Java SE 21 & JDK 21)
    ### Key Details on WeakHashMap
  56. [56]
    The SortedSet Interface - The Java™ Tutorials
    A SortedSet is a Set that maintains its elements in ascending order, sorted according to the elements' natural ordering or according to a Comparator provided ...
  57. [57]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/EnumMap.html
  58. [58]
    SortedSet (Java SE 21 & JDK 21) - Oracle Help Center
    All elements inserted into a sorted set must implement the Comparable interface (or be accepted by the specified comparator). Furthermore, all such elements ...
  59. [59]
    SortedMap (Java SE 21 & JDK 21)
    ### Summary of SortedMap Interface
  60. [60]
    Comparator (Java SE 21 & JDK 21)
    ### Summary of Comparator Interface (Java SE 21)
  61. [61]
    TreeSet (Java SE 21 & JDK 21)
    ### Summary of TreeSet (Java SE 21)
  62. [62]
    TreeMap (Java SE 21 & JDK 21)
    ### Summary of TreeMap (Java SE 21)
  63. [63]
    java.util.concurrent (Java SE 21 & JDK 21)
    ### Summary of Concurrent Interfaces in java.util.concurrent
  64. [64]
    https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Comparator.html
  65. [65]
    https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/TreeSet.html
  66. [66]
    https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/TreeMap.html
  67. [67]
    ConcurrentHashMap (Java SE 21 & JDK 21)
    ### Summary of ConcurrentHashMap Implementation Details
  68. [68]
    CopyOnWriteArrayList (Java SE 21 & JDK 21) - Oracle Help Center
    A thread-safe variant of ArrayList in which all mutative operations ( add , set , and so on) are implemented by making a fresh copy of the underlying array.
  69. [69]
    ArrayBlockingQueue (Java SE 21 & JDK 21)
    ### Summary of ArrayBlockingQueue Implementation
  70. [70]
    LinkedBlockingQueue (Java SE 21 & JDK 21)
    ### Summary of LinkedBlockingQueue
  71. [71]
    ConcurrentSkipListSet (Java SE 21 & JDK 21)
    ### Summary of ConcurrentSkipListSet
  72. [72]
    Collections.synchronizedMap vs. ConcurrentHashMap | Baeldung
    Jan 8, 2024 · In this tutorial, we'll discuss the differences between Collections.synchronizedMap() and ConcurrentHashMap. Additionally, we'll look at the ...
  73. [73]
    JEP 431: Sequenced Collections - OpenJDK
    Jan 27, 2022 · We define new interfaces for sequenced collections, sequenced sets, and sequenced maps, and then retrofit them into the existing collections type hierarchy.
  74. [74]
    SequencedCollection (Java SE 21 & JDK 21) - Oracle Help Center
    A collection that has a well-defined encounter order, that supports operations at both ends, and that is reversible.
  75. [75]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ConcurrentSkipListSet.html
  76. [76]
    JEP 269: Convenience Factory Methods for Collections - OpenJDK
    Jun 26, 2014 · Provide static factory methods on the collection interfaces that will create compact, unmodifiable collection instances. The API is deliberately kept minimal.
  77. [77]
    The State of the Module System - OpenJDK
    Mar 8, 2016 · The base module defines and exports all of the platform's core packages, including the module system itself: module java.base { exports java.io; ...
  78. [78]
    JDK 8u20 Update Release Notes - Java SE
    String deduplication reduces the memory footprint of String objects on the Java heap by taking advantage of the fact that many String objects are identical.
  79. [79]
    JDK 25 Release Notes, Important Changes, and Information - Oracle
    Sep 16, 2025 · These notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK ...Missing: framework | Show results with:framework<|separator|>
  80. [80]
    JEP 444: Virtual Threads - OpenJDK
    Mar 6, 2023 · This JEP proposes to finalize virtual threads in JDK 21 with the following changes from JDK 20, informed by developer feedback: Virtual threads ...
  81. [81]
    Collections (Java SE 21 & JDK 21)
    ### Summary of `java.util.Collections` Class and Methods
  82. [82]
    https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#addAll-java.util.Collection-T...-
  83. [83]
    https://openjdk.org/jeps/269
  84. [84]
    https://openjdk.org/projects/jigsaw/spec/sotms/
  85. [85]
    https://www.oracle.com/java/technologies/javase/8u20-relnotes.html
  86. [86]
    https://www.oracle.com/java/technologies/javase/25-relnote-issues.html
  87. [87]
    https://openjdk.org/jeps/444
  88. [88]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html
  89. [89]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#sort(java.util.List)
  90. [90]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#reverse(java.util.List)
  91. [91]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#shuffle(java.util.List)
  92. [92]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#unmodifiableList(java.util.List)
  93. [93]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#singletonList(T)
  94. [94]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#emptyList()
  95. [95]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#synchronizedList(java.util.List)
  96. [96]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#synchronizedMap(java.util.Map)
  97. [97]
    https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#min(java.util.Collection)
  98. [98]
    https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html#stream--
  99. [99]
    Processing Data with Java SE 8 Streams, Part 1 - Oracle
    Java SE 8 to the rescue! The Java API designers are updating the API with a new abstraction called Stream that lets you process data in a declarative way.Stream Operations... · Numeric Streams · Building Streams
  100. [100]
    https://www.oracle.com/technical-resources/articles/java/ma14-java-se-8-streams.html
  101. [101]
    https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html
  102. [102]
    Lambda Expressions (The Java™ Tutorials > Learning the Java ...
    A stream is a sequence of elements. Unlike a collection, it is not a data structure that stores elements. Instead, a stream carries values from a source, such ...Ideal Use Case for Lambda... · Approach 8: Use Generics...
  103. [103]
    java.base (Java SE 11 & JDK 11 ) - Oracle Help Center
    Provides classes that are fundamental to the design of the Java programming language. · Provides library support for the Java programming language annotation ...
  104. [104]
    JEP 441: Pattern Matching for switch - OpenJDK
    Jan 18, 2023 · Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action.
  105. [105]
    Virtual Threads - Oracle Help Center
    Virtual threads are lightweight threads that reduce the effort of writing, maintaining, and debugging high-throughput concurrent applications.