In Lecture 7 we learned how Java reports and recovers from failures with exceptions. In this lecture we move to the part of the standard library you will use in every single Java program you ever write: the Java Collections Framework (JCF) and Generics.

A collection is simply an object that holds a group of other objects. Arrays can do that too, but arrays have a fixed size, cannot grow, have no built-in search or sort behaviour, and cannot tell you whether an element is already present without a loop. The Collections Framework, introduced in Java 1.2 and heavily upgraded in Java 5 (generics), Java 8 (lambdas, default methods), Java 9 (immutable factories) and Java 21 (sequenced collections), gives you ready-made, battle-tested data structures: resizable lists, hash tables, sorted trees, queues, stacks and more.

Why does this matter in real projects?

• Every backend API returns a List of DTOs, caches lookups in a Map, de-duplicates IDs with a Set, and processes jobs from a Queue.
• Performance depends on choosing the right structure. A contains() check on an ArrayList of 1,00,000 user IDs scans every element (O(n)); the same check on a HashSet is effectively constant time (O(1)). Picking wrong can turn a 5 ms request into a 5 second one.
• Interviews at Indian service companies, product companies and startups alike almost always include "ArrayList vs LinkedList", "HashMap vs HashSet" and "how does HashMap work internally". This lecture answers all of those with the depth interviewers expect.

Generics are the second half of the story. Before Java 5, a List held plain Objects, so you had to cast on every get() and could accidentally put a String into a list of Integers. Generics let you write List<Integer> so the compiler enforces the element type and the cast disappears. Understanding generics properly, including bounded types, wildcards and type erasure, is what separates developers who copy-paste collection code from developers who can design reusable libraries.

By the end of this lecture you will know which collection to pick for which job, how the most important ones are implemented, how to sort and iterate them safely, and how to write your own generic classes and methods.

The framework is organised as a set of interfaces (what a structure can do) and implementation classes (how it does it). Learning the hierarchy once makes every API feel familiar.

At the top sits Iterable<T>, which only promises an iterator() method; it is what makes the for-each loop work. Below it is Collection<E>, the root of everything except maps. Collection declares the universal operations: add, remove, contains, size, isEmpty, clear, addAll, removeIf, stream and so on. From Collection hang three families:

• List<E> — an ordered sequence that allows duplicates and positional access by index. Implementations: ArrayList, LinkedList, and the legacy Vector and Stack.
• Set<E> — no duplicates. HashSet (unordered), LinkedHashSet (insertion order) and TreeSet (sorted, via SortedSet/NavigableSet).
• Queue<E> — elements processed in a particular order, usually FIFO. Deque<E> extends it for double-ended access. Implementations: ArrayDeque, LinkedList, PriorityQueue, and the concurrent ArrayBlockingQueue/LinkedBlockingQueue.

Map<K, V> is a separate root. A map is not a Collection because it stores pairs rather than single elements, but its views (keySet(), values(), entrySet()) are collections. Implementations: HashMap, LinkedHashMap, TreeMap (via SortedMap/NavigableMap), the legacy Hashtable, and ConcurrentHashMap for multi-threaded use.

Two utility classes complete the picture: Collections (static helpers such as sort, reverse, shuffle, unmodifiableList, synchronizedMap, emptyList) and Arrays (asList, sort, binarySearch, stream).

Program to the interface. Declare variables as List<String> names = new ArrayList<>(); rather than ArrayList<String> names = .... Your code then depends only on the contract, and you can swap the implementation (for example to LinkedList or CopyOnWriteArrayList) without touching the rest of the class. Method parameters and return types should almost always use the interface type too.

A List keeps elements in insertion order, allows duplicates and lets you access elements by index. The two implementations you must know are ArrayList and LinkedList; they have the same interface but very different internals.

ArrayList stores elements in a plain Java array behind the scenes. When you create one with the no-argument constructor, the internal array is empty and is allocated with a capacity of 10 on the first add. When the array fills up, ArrayList creates a new array 1.5 times larger (oldCapacity + (oldCapacity >> 1)) and copies everything over. That copy is O(n), but it happens so rarely that add at the end is amortised O(1). Reading by index (get(i)) is a direct array lookup: O(1). Inserting or removing in the middle shifts every element after it with System.arraycopy: O(n). contains and indexOf scan linearly: O(n).

LinkedList is a doubly linked list: each element lives in a Node object holding the value plus prev and next references. Adding or removing at either end is O(1) because only two pointers change. But get(i) has to walk from the nearest end, node by node, so it is O(n); a loop calling get(i) over a LinkedList of n elements is O(n²). Each node also costs roughly 24 extra bytes on a 64-bit JVM plus a pointer hop that defeats CPU caching, which is why ArrayList wins even in many "insert in the middle" benchmarks once you include the cost of finding the position.

When to use which:

• Default to ArrayList. It is faster for random access, iteration and memory, and is what 95 percent of production code uses.
• Consider LinkedList only when you repeatedly add and remove at the front and never index into the list. Even then, ArrayDeque is usually a better choice (Section 6).
• If you know the size in advance, pass it to the constructor (new ArrayList<>(1_00_000)) or call ensureCapacity to avoid repeated resizing.

Useful List methods beyond the basics: subList(from, to) (a live view, not a copy), indexOf, lastIndexOf, set(i, e), sort(comparator), replaceAll(unaryOp), List.of(...) and List.copyOf(...), and since Java 21 getFirst, getLast, removeFirst, removeLast and reversed().

A Set is a collection with no duplicate elements. Calling add with an element that is already present returns false and leaves the set unchanged. Which element counts as "already present" depends on equals() and hashCode() for hash-based sets, and on compareTo()/Comparator for TreeSet. The three implementations differ only in ordering and performance.

HashSet is backed by a HashMap internally: every element you add becomes a key, and the value is a shared dummy object called PRESENT. That means add, remove and contains are O(1) on average, and everything you will learn about HashMap in Section 5 applies here. The iteration order is unspecified and can change when the set resizes, so never write code that depends on it.

LinkedHashSet extends HashSet but additionally threads a doubly linked list through the entries, so iteration follows insertion order. The cost is a little extra memory per element. This is the right choice when you want de-duplication but must preserve the order the user supplied, for example "remove duplicate rows but keep the first occurrence".

TreeSet is backed by a red-black tree (through TreeMap). Elements are kept sorted, either by their natural order (Comparable) or by a Comparator you pass to the constructor. Operations are O(log n). Because it implements NavigableSet, you get powerful range queries: first(), last(), floor(e) (greatest element ≤ e), ceiling(e) (least element ≥ e), lower, higher, headSet(to), tailSet(from), subSet(from, to), pollFirst() and descendingSet(). Elements must be mutually comparable; adding a null to a TreeSet with natural ordering throws NullPointerException, while HashSet and LinkedHashSet allow exactly one null.

Important subtlety: TreeSet decides equality using compareTo (or the comparator), not equals. If your comparator compares only by salary, two different employees with the same salary are treated as duplicates and the second one is silently dropped.

Choose: HashSet for fast membership checks, LinkedHashSet when order matters, TreeSet when you need sorted data or range queries.

A Map<K, V> stores key-value pairs where each key appears at most once. It is the structure you reach for whenever you need to look something up by an identifier: user ID to profile, product code to price, word to frequency.

HashMap is the workhorse. put, get, remove and containsKey run in O(1) on average. It allows one null key and any number of null values, and makes no ordering promise. Internally it is an array of buckets indexed by the key's hash code; Section 6 dissects it.

LinkedHashMap adds a doubly linked list through its entries so iteration follows insertion order by default. Pass true as the third constructor argument (accessOrder) and it switches to access order, moving an entry to the end every time it is read. Combined with the protected removeEldestEntry hook, this gives you an LRU cache in five lines, a classic interview question.

TreeMap keeps keys sorted in a red-black tree, so every operation is O(log n), and it implements NavigableMap: firstKey, lastKey, floorKey, ceilingKey, headMap, tailMap, subMap, firstEntry, pollFirstEntry and descendingMap. Use it for anything that needs range lookups, such as "which tax slab does ₹8,50,000 fall into" or "the nearest scheduled train after 09:15". TreeMap does not allow a null key with natural ordering.

Legacy and concurrent variants: Hashtable is the Java 1.0 ancestor: synchronized on every method, no nulls, and slow; do not use it in new code. For multi-threaded access use ConcurrentHashMap, which locks per bucket and also forbids null keys and values.

Java 8 convenience methods you should use instead of the old if (map.containsKey(k)) dance: getOrDefault(k, def), putIfAbsent(k, v), computeIfAbsent(k, fn) (perfect for building a map of lists), computeIfPresent, merge(k, v, fn) (perfect for counting), forEach((k, v) -> ...) and replaceAll. Iterate with entrySet() when you need both key and value; it avoids a second lookup per element.

"Explain the internal working of HashMap" is asked in almost every Java interview from 2 to 10 years of experience. Here is the complete answer for Java 8 and later.

Storage. A HashMap holds an array called table of type Node<K,V>[]. Each slot is a bucket. The default initial capacity is 16 and the default load factor is 0.75, so the threshold (the size at which the table grows) starts at 16 × 0.75 = 12 entries. Capacity is always a power of two.

put(key, value) step by step:

1. Compute key.hashCode(). For a null key the hash is 0, which is why one null key is allowed (bucket 0).
2. Spread the hash: hash = h ^ (h >>> 16). This XORs the high 16 bits into the low 16 bits so that keys whose hash codes differ only in the upper bits still land in different buckets.
3. Compute the bucket index as (n - 1) & hash, where n is the table length. Because n is a power of two, this is a fast equivalent of hash % n.
4. If the bucket is empty, create a new Node(hash, key, value, next) and store it.
5. If the bucket already has nodes (a collision), walk them. For each node, first compare the stored hash (cheap int compare); only if the hashes match call equals(). If an equal key is found, replace the value and return the old one. Otherwise append a new node to the end of the chain.
6. Increment size and modCount. If size > threshold, resize.

Resize. The table doubles (16 → 32 → 64...) and every node is redistributed. Thanks to the power-of-two trick, each chain splits into exactly two: nodes stay at the same index or move to index + oldCapacity, decided by one bit of the hash. Resizing is O(n), so if you know you will insert 10,000 entries, construct with new HashMap<>(16_384) or, since Java 19, HashMap.newHashMap(10_000), which computes the right capacity for you.

Treeification (Java 8). If a single bucket's chain grows to 8 nodes (TREEIFY_THRESHOLD) and the table has at least 64 buckets (MIN_TREEIFY_CAPACITY), the chain is converted into a red-black tree, turning worst-case lookup from O(n) to O(log n). If the table is smaller than 64, HashMap resizes instead. When a tree bucket shrinks to 6 nodes (UNTREEIFY_THRESHOLD) during resize, it turns back into a list. This change protects against hash-collision denial-of-service attacks where an attacker sends thousands of keys with identical hash codes.

get(key) repeats steps 1 to 3, then walks the bucket comparing hash and then equals, returning the value or null.

The equals/hashCode contract. If a.equals(b) then a.hashCode() == b.hashCode() must hold. Override one and you must override the other, otherwise equal keys land in different buckets and get returns null for a key you just stored. Records and IDEs generate both for you. Keys should also be immutable: if a key's hash changes after insertion, it is stranded in the wrong bucket forever. This is why String, Integer and records make ideal keys, and why String caches its hash code.

Not thread-safe. Concurrent put calls from multiple threads can lose entries; before Java 8 they could even create an infinite loop during resize. Use ConcurrentHashMap for shared maps.

A Queue processes elements in a defined order, typically first-in, first-out (FIFO): print jobs, HTTP requests waiting for a worker thread, customers at a counter. The Queue interface offers each operation in two flavours: one that throws an exception on failure and one that returns a special value.

• Insert: add(e) throws if the queue is full (bounded queues only); offer(e) returns false.
• Remove head: remove() throws NoSuchElementException when empty; poll() returns null.
• Inspect head: element() throws when empty; peek() returns null.

Prefer offer/poll/peek in application code and reserve the throwing versions for cases where emptiness is a real bug.

Deque (double-ended queue, pronounced "deck") extends Queue and lets you add and remove from both ends: addFirst/addLast, offerFirst/offerLast, pollFirst/pollLast, peekFirst/peekLast, plus the stack methods push (= addFirst) and pop (= removeFirst).

ArrayDeque is the implementation you should use for both queues and stacks. It is a circular, resizable array with O(1) operations at both ends, no per-element node objects and better cache behaviour than LinkedList. The old java.util.Stack class extends Vector, synchronizes every method and exposes index-based access that breaks the stack abstraction; the Javadoc itself recommends ArrayDeque instead. Note that ArrayDeque does not accept null elements, precisely because poll and peek use null to mean "empty".

PriorityQueue is different: it hands out elements by priority, not arrival order. It is a binary min-heap stored in an array; offer and poll are O(log n), peek is O(1). The head is the smallest element according to natural ordering or a supplied Comparator. Two things trip people up: iterating a PriorityQueue (or printing it) does not give sorted order, only poll() does; and it is not thread-safe (use PriorityBlockingQueue). Typical uses: Dijkstra's algorithm, task schedulers, "top K" problems, and merging sorted streams.

For producer-consumer work across threads use the BlockingQueue implementations (ArrayBlockingQueue, LinkedBlockingQueue), whose put and take methods block until space or an element is available.

For twenty years the framework had an awkward gap. List, Deque, LinkedHashSet and LinkedHashMap all have a well-defined encounter order, yet there was no common type to express it. Getting the last element of a List meant list.get(list.size() - 1); for a LinkedHashSet you had to iterate to the end or convert to a list; for a Deque it was getLast(). Every type spelled the same idea differently.

JEP 431, Sequenced Collections, finalised in Java 21, fixes this with three new interfaces retrofitted into the hierarchy:

• SequencedCollection<E> extends Collection and adds getFirst(), getLast(), addFirst(e), addLast(e), removeFirst(), removeLast() and reversed(). List and Deque now extend it.
• SequencedSet<E> extends both SequencedCollection and Set. LinkedHashSet and SortedSet (hence TreeSet) implement it. On a LinkedHashSet, addFirst/addLast move an existing element to that end; on a TreeSet they throw UnsupportedOperationException because the order is determined by sorting.
• SequencedMap<K,V> adds firstEntry(), lastEntry(), pollFirstEntry(), pollLastEntry(), putFirst(k,v), putLast(k,v), reversed(), and sequenced views sequencedKeySet(), sequencedValues() and sequencedEntrySet(). LinkedHashMap and SortedMap (hence TreeMap) implement it.

reversed() returns a view, not a copy. Changes made through the view affect the original and vice versa, and the view costs no extra memory. It is ideal for iterating backwards with a plain for-each loop, which previously required a ListIterator or an index loop.

getFirst()/getLast() throw NoSuchElementException on an empty collection, so guard with isEmpty() where emptiness is normal.

The Collections class also gained unmodifiableSequencedCollection, unmodifiableSequencedSet and unmodifiableSequencedMap in Java 21. Note that HashSet and HashMap are not sequenced because they have no defined order. If your project is still on Java 17 these methods do not exist; this is one of the most visible everyday improvements when upgrading to Java 21 or Java 25.

Immutable collections cannot be changed after creation. They are safe to share between threads, safe to return from a method without defensive copying, safe to use as map keys, and they make bugs like "who cleared my list?" impossible. Modern Java gives you several ways to create them, and they are not interchangeable.

Convenience factories (Java 9). List.of(a, b, c), Set.of(a, b, c) and Map.of(k1, v1, k2, v2, ...) create truly immutable collections. Rules you must remember:

• They reject null elements, keys and values with NullPointerException.
• Set.of and Map.of reject duplicates with IllegalArgumentException at creation time.
• Map.of accepts up to 10 key-value pairs; beyond that use Map.ofEntries(Map.entry(k, v), ...).
• Any mutator (add, remove, set, put, clear, sort) throws UnsupportedOperationException.
• Iteration order of Set.of and Map.of is deliberately randomised per JVM run so you cannot accidentally depend on it.

Copy factories (Java 10). List.copyOf(collection), Set.copyOf and Map.copyOf create an immutable snapshot. If the argument is already an immutable collection of the same kind, no copy is made.

Unmodifiable views (Java 1.2). Collections.unmodifiableList(list) returns a view that blocks modification through the view, but if someone still holds the original list and changes it, the view changes too. Use it when you want to expose read-only access to a collection that you keep mutating internally.

Stream results. Stream.toList() (Java 16) returns an unmodifiable list. Collectors.toList() returns a list whose mutability is unspecified (in practice an ArrayList, but do not rely on it); use Collectors.toCollection(ArrayList::new) when you need a guaranteed mutable list.

Arrays.asList is the odd one out: it returns a fixed-size list backed by the array. set works and writes through to the array; add and remove throw. It is not immutable and not resizable.

Rule of thumb: use List.of/Map.of for constants and small fixed data; use List.copyOf when returning internal state from a method; wrap with new ArrayList<>(...) when the caller legitimately needs to modify.

Sorting needs a rule for deciding which of two elements comes first. Java offers two ways to express that rule.

Comparable<T> is implemented by the class itself and defines its natural ordering through a single method, int compareTo(T other). Return a negative number if this comes before other, zero if they are equal in ordering, positive if after. String, Integer, LocalDate, BigDecimal and all enums are Comparable. A class can have only one natural order. Collections.sort(list), TreeSet, TreeMap and Arrays.sort all use it when no comparator is given. Strongly recommended: keep compareTo consistent with equals (returns 0 exactly when equals is true), otherwise TreeSet and TreeMap behave strangely.

Comparator<T> is a separate object that defines an ordering from outside the class. You can have as many as you like: by name, by salary descending, by joining date then name. It has one abstract method, int compare(T a, T b), so it is a functional interface and can be written as a lambda. Pass it to list.sort(cmp), Collections.sort(list, cmp), stream.sorted(cmp), new TreeSet<>(cmp), new TreeMap<>(cmp) or new PriorityQueue<>(cmp).

Since Java 8 you should almost never write a compare method by hand. The static and default methods on Comparator compose readable, bug-free orderings:

• Comparator.comparing(Employee::getName) — by a key.
• Comparator.comparingInt(Employee::getAge) / comparingDouble / comparingLong — avoid boxing.
• .thenComparing(...) — tie-breaker.
• .reversed() — flip the order (apply it to the right part of the chain).
• Comparator.naturalOrder() / reverseOrder().
• Comparator.nullsFirst(cmp) / nullsLast(cmp) — handle null elements instead of crashing.
• String.CASE_INSENSITIVE_ORDER — for case-insensitive text.

Pitfalls. Writing return a.salary - b.salary; overflows for large or negative numbers; use Integer.compare(a, b). Sorting a List.of(...) result throws because it is immutable; copy it first. Collections.sort and List.sort are stable (equal elements keep their relative order), which matters when you sort by one field then another in separate passes.

One of the first runtime surprises every Java developer hits is ConcurrentModificationException (CME). Despite the name, it has nothing to do with threads in most cases. It happens when you modify a collection structurally (add or remove, not set) while iterating it with a for-each loop or an iterator obtained earlier.

Why it happens. ArrayList, HashMap and friends keep an internal counter called modCount, incremented on every structural change. When you call iterator(), the iterator remembers the current modCount. On every next() it compares its copy with the live value; if they differ, it throws CME. This is called fail-fast behaviour, and it exists to surface bugs early rather than returning garbage. Note the check is best-effort: removing the second-to-last element sometimes ends the loop without throwing, which makes the bug intermittent and harder to find.

Safe ways to remove while iterating:

1. Iterator.remove() — the classic approach. Get an explicit Iterator, and call it.remove() after it.next(). The iterator updates its expected modCount, so no exception.
2. Collection.removeIf(predicate) (Java 8) — one line, fastest and clearest. ArrayList overrides it with an optimised single pass. Works on map.keySet(), map.values() and map.entrySet() too.
3. ListIterator — like Iterator but also supports add, set and backward traversal with hasPrevious/previous.
4. Index loop running backwards — for (int i = list.size() - 1; i >= 0; i--); removing element i does not shift the elements you have yet to visit.
5. Iterate over a copy — for (String s : new ArrayList<>(list)); simple but O(n) extra memory.
6. Concurrent collections — CopyOnWriteArrayList and ConcurrentHashMap never throw CME. Their iterators are weakly consistent: they reflect the state at some point since creation and may or may not show later changes. CopyOnWriteArrayList copies the whole array on every write, so it is only suitable for read-mostly data such as listener lists.

For maps, do not call map.remove(key) inside a loop over map.keySet(); use map.entrySet().removeIf(e -> ...) or an explicit iterator on entrySet(). Updating values during iteration (entry.setValue(...)) is allowed because it is not a structural change.

Generics (Java 5) let you write classes, interfaces and methods that are parameterised by type. Instead of a Box that holds an Object and forces casts everywhere, you write Box<T> once and use it as Box<String>, Box<Integer> or Box<Employee> with full compile-time type checking.

Why they matter: without generics, List names = new ArrayList(); names.add(42); compiles and only blows up later with a ClassCastException when someone does (String) names.get(0). With List<String>, the same mistake is a compile error on the line that is actually wrong. Generics turn runtime failures into compile-time failures and remove casting noise.

Generic class. Declare type parameters in angle brackets after the class name: class Pair<K, V> { ... }. Inside, K and V act like types. Conventional names: T (type), E (element), K/V (key/value), N (number), R (result). Since Java 7 the diamond operator new Pair<>(...) lets the compiler infer the arguments.

Generic method. Declare the type parameter before the return type: static <T> T firstOrDefault(List<T> list, T def). The compiler infers T from the arguments at each call site, so you rarely write Util.<String>firstOrDefault(...) explicitly. A generic method can live in a non-generic class, and a static method cannot use the class's type parameter because there is no instance to tie it to.

Bounded type parameters restrict what T can be, which in turn lets you call methods on it. <T extends Number> means T must be Number or a subclass, so you can call t.doubleValue(). <T extends Comparable<T>> means you can call compareTo, which is exactly what a generic max method needs. Note that extends is used for both classes and interfaces in bounds. Multiple bounds are written with &: <T extends Number & Comparable<T>>; a class bound, if any, must come first.

The recursive-looking bound <T extends Comparable<? super T>> is the most flexible form for sorting utilities because it also accepts subclasses whose parent implements Comparable; it is what Collections.sort actually declares.

Generic interfaces work the same way: interface Repository<T, ID> { Optional<T> findById(ID id); } is exactly the pattern Spring Data uses for JpaRepository<Employee, Long>.

Generics are invariant. Even though Integer is a subtype of Number, List<Integer> is not a subtype of List<Number>. If it were, you could write List<Number> nums = integers; nums.add(3.14); and corrupt the integer list. So a method declared as void printAll(List<Number> list) cannot accept a List<Integer>. Wildcards solve this.

Three kinds of wildcard:

• List<?> (unbounded) — a list of some unknown type. You can read elements as Object and call size/isEmpty, but you cannot add anything except null. Use it when the method only needs Collection-level operations.
• List<? extends Number> (upper bounded) — a list of Number or some subtype. You can safely read elements as Number, but you cannot add because the compiler does not know whether it is really a List<Integer> or List<Double>.
• List<? super Integer> (lower bounded) — a list of Integer or some supertype (Number, Object). You can safely add an Integer, but reading only gives you Object.

PECS: Producer Extends, Consumer Super (Joshua Bloch, Effective Java). If a parameter produces values for your method to read, use ? extends T. If it consumes values your method writes, use ? super T. If it does both, use the exact type T. The JDK's own Collections.copy(List<? super T> dest, List<? extends T> src) is the textbook example; so is Collections.sort(List<T>, Comparator<? super T>), which lets a Comparator<Object> sort a List<String>.

Type erasure. Generics exist only at compile time. The compiler checks your types, inserts casts where needed, and then erases every type parameter: T becomes Object (or its first bound, e.g. Comparable), and List<String> becomes plain List in the bytecode. This was done so Java 5 code could run on older JVMs and interoperate with pre-generics libraries. Where a subclass overrides a generic method with a concrete type, the compiler generates a hidden bridge method to keep overriding working after erasure.

Consequences you must know for interviews:

• new ArrayList<String>().getClass() == new ArrayList<Integer>().getClass() is true.
• obj instanceof List<String> does not compile; only instanceof List<?> is allowed.
• You cannot write new T(), new T[10] or T.class. Pass a Class<T> token or an array factory instead.
• Primitive types cannot be type arguments: List<int> is illegal, use List<Integer> (autoboxing costs memory and time; streams offer IntStream to avoid it).
• A static field cannot have type T, because statics are shared across all parameterisations.
• Two methods void f(List<String> l) and void f(List<Integer> l) cannot coexist because they erase to the same signature.
• Generic arrays plus varargs can cause heap pollution; the compiler warns, and @SafeVarargs is how a library author promises the method is safe.

Here is how the structures from this lecture show up in real Java systems, with the reasoning behind each choice.

REST APIs with Spring Boot. Controllers return List<OrderDto>; service layers build Map<Long, Customer> lookups so that a loop over 5,000 orders does not hit the database 5,000 times (the classic N+1 problem). Spring Data's JpaRepository<T, ID> is itself a generic interface, so understanding bounded types is what lets you read its source without fear.

De-duplication and membership checks. Payment gateways store processed transaction IDs in a HashSet<String> (or in Redis for distributed systems) so a retried webhook is ignored in O(1). An e-commerce "recently viewed" widget is a LinkedHashSet capped at 10 entries: duplicates collapse and insertion order is preserved.

Caching. A LinkedHashMap in access order with removeEldestEntry is a production-grade in-process LRU cache for small datasets such as pincode-to-city lookups. Libraries like Caffeine implement the same idea with concurrency and expiry on top.

Scheduling and rate limiting. A PriorityQueue<Job> ordered by runAt timestamp drives a simple scheduler: peek the head, sleep until its time, poll and execute. A sliding-window rate limiter keeps request timestamps in an ArrayDeque<Long> and polls expired ones from the front.

Range lookups. TreeMap<Integer, String> with floorEntry resolves tax slabs, shipping charges by weight, or the correct version of a config that was valid at a timestamp. Consistent-hashing load balancers use TreeMap<Integer, Node> with ceilingEntry to find the next node on the ring.

Streaming and batching. Kafka consumers collect records into an ArrayList with a known capacity and flush every 500 records; using new ArrayList<>(500) avoids four internal resizes per batch.

Multi-threaded services. Shared counters and registries use ConcurrentHashMap with merge and computeIfAbsent, which are atomic per key. Event listener lists use CopyOnWriteArrayList because reads vastly outnumber writes.

Generic utilities. Teams write ApiResponse<T>, Page<T>, Result<T, E> and Validator<T> once and reuse them across every endpoint. Wildcards appear whenever a utility accepts "any list of DTOs": void audit(List<? extends BaseEntity> changed).

Android and desktop UI. A RecyclerView adapter holds a List<Item>; stable sorting with chained comparators keeps grouped sections in order when the user changes the sort key.

1. Using == or forgetting equals/hashCode on map keys and set elements. A custom Employee class without both methods means set.contains(new Employee("E1")) is always false and the map stores duplicates. Fix: generate both methods, or use a record, which does it for you.

2. Mutating a key after inserting it. The entry is stranded in the old bucket. Fix: use immutable keys (String, Integer, records with immutable fields) or remove and re-insert.

3. Removing inside a for-each loop. Causes ConcurrentModificationException, sometimes only on certain inputs. Fix: removeIf or Iterator.remove().

4. Using LinkedList "because insertions are fast". The cost of finding the position dominates, and memory per element is three times higher. Fix: default to ArrayList; use ArrayDeque for queue or stack behaviour.

5. Using list.contains() in a loop. Checking 10,000 items against a 10,000-element list is 10⁸ comparisons. Fix: convert the lookup side to a HashSet first; the whole job becomes O(n).

6. Depending on HashMap/HashSet iteration order. It changes between JVM versions, on resize, and Set.of/Map.of randomise it on purpose. Fix: LinkedHashMap for insertion order, TreeMap for sorted order.

7. Subtracting in compareTo. return a.price - b.price; overflows for large values and does not work for doubles at all. Fix: Integer.compare, Double.compare, or Comparator.comparing.

8. Comparator inconsistent with equals in TreeSet/TreeMap. Elements that compare as 0 are treated as the same element. Fix: add a unique tie-breaker (.thenComparing(Employee::id)).

9. Modifying a List.of result or the list returned by Stream.toList(). Throws UnsupportedOperationException. Fix: wrap in new ArrayList<>(...) when mutation is needed.

10. Putting null where it is not allowed. List.of, Map.of, ArrayDeque, TreeMap keys, ConcurrentHashMap keys and values all reject it with NullPointerException. Fix: use Optional or a sentinel, or choose HashMap/ArrayList which allow nulls.

11. Using raw types. List list = new ArrayList(); silently disables type checking and produces unchecked warnings. Fix: always supply type arguments; use List<?> when the element type is genuinely unknown.

12. Returning internal collections directly from getters. Callers can mutate your object's state. Fix: return List.copyOf(internal) or Collections.unmodifiableList(internal).

13. Autoboxing in hot loops. Map<Integer, Integer> counting in a tight loop allocates millions of Integer objects. Fix: use primitive arrays or specialised libraries (Eclipse Collections, fastutil) when profiling shows it matters.

14. Using Hashtable, Vector or Stack. They are legacy and slow. Fix: HashMap/ConcurrentHashMap, ArrayList, ArrayDeque.

What is the difference between ArrayList and LinkedList in Java?

ArrayList stores elements in a resizable array, giving O(1) index access and compact memory; inserting in the middle is O(n) because elements shift. LinkedList stores each element in a node with prev/next pointers, giving O(1) insertion and removal at the ends but O(n) index access and much higher memory use. In practice ArrayList is faster for almost every workload, and ArrayDeque beats LinkedList for queue and stack use.

What is the difference between HashMap and HashSet?

HashMap stores key-value pairs; HashSet stores only unique elements. HashSet is actually implemented on top of a HashMap: each element becomes a key and the value is a shared dummy object. Both give O(1) average add/contains, both depend on correct equals and hashCode, and both allow one null.

What is the difference between HashMap and Hashtable?

Hashtable is a legacy class from Java 1.0 that synchronizes every method, forbids null keys and values, and is slower. HashMap is unsynchronized, allows one null key, and is the standard choice. For thread safety use ConcurrentHashMap, not Hashtable.

How does HashMap work internally in Java?

It keeps an array of buckets. A key's hashCode() is spread with h ^ (h >>> 16) and masked with (n - 1) to pick a bucket. Collisions form a linked list, which converts to a red-black tree at 8 nodes (when the table has at least 64 buckets). When size exceeds capacity × 0.75 the table doubles and entries are redistributed. Lookups compare the stored hash first and then call equals.

What is the difference between Comparable and Comparator in Java?

Comparable is implemented by the class itself (compareTo) and defines one natural order. Comparator is a separate object (compare) that defines an external order, so you can have many of them and build them with Comparator.comparing and thenComparing. Use Comparable for the obvious default order and Comparator for everything else.

What are sequenced collections in Java 21?

JEP 431 added SequencedCollection, SequencedSet and SequencedMap with uniform getFirst, getLast, addFirst, addLast, removeFirst, removeLast and reversed() methods. List, Deque, LinkedHashSet, TreeSet, LinkedHashMap and TreeMap all gained them. reversed() returns a live view.

What is type erasure in Java generics?

The compiler checks generic types and then removes them from the bytecode, replacing T with Object or its bound. That is why List<String> and List<Integer> have the same runtime class, why you cannot write new T() or instanceof List<String>, and why primitives cannot be type arguments. It was chosen for backward compatibility with pre-Java 5 code.

When should I use List.of instead of new ArrayList?

Use List.of (Java 9) for fixed data that should never change: constants, test fixtures, values returned from a method. It is compact, thread-safe and rejects nulls. Use new ArrayList<>() when the list will be modified. Use List.copyOf to return an immutable snapshot of internal state.

Q1. Why is the load factor of HashMap 0.75 and what happens when it is exceeded?

0.75 is a trade-off between memory and lookup time: higher values pack more entries per bucket (more collisions), lower values waste array slots. When size exceeds capacity × loadFactor (12 for the default 16), the table doubles and every entry is rehashed into the new array, an O(n) operation. Pre-sizing the map avoids repeated resizes.

Q2. Why should HashMap keys be immutable?

The bucket index is computed from the key's hash code at insertion time. If the key's state (and therefore its hash) changes afterwards, get computes a different index and cannot find the entry, while size still counts it. Immutable keys like String, Integer and records avoid this.

Q3. What happens if two keys have the same hashCode in a HashMap?

They land in the same bucket (a collision). HashMap walks the bucket and uses equals to distinguish them. Entries are chained in a linked list, converted to a red-black tree when the chain reaches 8 nodes and the table has at least 64 buckets, giving O(log n) worst-case instead of O(n).

Q4. What is the difference between fail-fast and fail-safe iterators?

Fail-fast iterators (ArrayList, HashMap) check a modCount on every next() and throw ConcurrentModificationException if the collection changed structurally. So-called fail-safe (more precisely weakly consistent) iterators in ConcurrentHashMap and CopyOnWriteArrayList work on a snapshot or tolerate concurrent changes and never throw, at the cost of possibly not seeing the latest updates.

Q5. How would you implement an LRU cache in Java?

Extend LinkedHashMap with accessOrder = true and override removeEldestEntry to return size() > capacity. Every get moves the entry to the tail; inserting beyond capacity evicts the head, which is the least recently used entry. All operations stay O(1).

Q6. What is the difference between List<Object>, List<?> and a raw List?

List<Object> is a list that may hold any object and you can add anything to it, but a List<String> cannot be passed where it is expected (invariance). List<?> accepts any parameterised list but only allows reading as Object and adding null. A raw List disables generic type checking completely and generates unchecked warnings; it exists only for legacy code.

Q7. Explain PECS with an example.

Producer Extends, Consumer Super. If a parameter supplies values you read, declare ? extends T so any subtype list is accepted: double sum(List<? extends Number>). If a parameter receives values you write, declare ? super T so any supertype list is accepted: void addAll(List<? super Integer>). Collections.copy(List<? super T> dest, List<? extends T> src) uses both.

Q8. Why can you not create a generic array like new T[10]?

Because of type erasure, T does not exist at runtime, so the JVM cannot know which array type to create. Arrays are reified and checked at runtime, generics are not. Workarounds are (T[]) new Object[10] with an unchecked warning (only safe if the array never escapes), or Array.newInstance(clazz, 10) with a Class<T> token.

Q9. What is the difference between Iterator and ListIterator?

Iterator works on any Collection and supports hasNext, next and remove. ListIterator works only on List, adds bidirectional traversal (hasPrevious, previous), index queries (nextIndex, previousIndex) and modification via set and add.

Q10. Which collection would you use for each: unique sorted words, task scheduling by deadline, undo history, counting word frequency, and a thread-safe registry?

TreeSet<String> for unique sorted words; PriorityQueue<Task> ordered by deadline; ArrayDeque<Action> used as a stack for undo; HashMap<String, Integer> with merge(word, 1, Integer::sum) for counting; ConcurrentHashMap for a registry shared across threads.

Put everything together by building a small inventory system for an electronics and stationery shop. The program uses:

• A generic repository InMemoryRepository<T, ID> backed by a LinkedHashMap, returning immutable snapshots with List.copyOf.
• A Product record that implements Comparable (natural order by name).
• A bounded generic method maxOf and a PECS method copyAll.
• TreeMap for grouping by category and for price range queries with headMap and ceilingEntry.
• Comparator chaining for sorting by price descending then name.
• PriorityQueue for low-stock restock ordering.
• Java 21 sequenced methods getFirst/getLast.
• removeIf for safe deletion and LinkedHashSet for ordered unique categories.

Compile and run with Java 21 or later: javac InventoryApp.java then java InventoryApp. Compare your output with the expected output in the comment at the bottom.

Extend it yourself:

1. Add a findByCategory(String) method to the repository using a wildcard-friendly signature List<? extends T>.
2. Replace the PriorityQueue with a TreeSet using a comparator on stock then SKU, and observe the difference in iteration order.
3. Make Product prices BigDecimal and sort with Comparator.comparing(Product::price).
4. Write an LruCache<K, V> from Section 5 and cache findById results.

• The Java Collections Framework separates interfaces (List, Set, Queue, Deque, Map) from implementations; always program to the interface.
• ArrayList is the default list (array-backed, O(1) index access, grows by 1.5×); LinkedList rarely wins. Use ArrayDeque for stacks and queues, never Stack or Vector.
• HashSet/HashMap give O(1) average operations but no order; LinkedHashSet/LinkedHashMap keep insertion (or access) order; TreeSet/TreeMap keep elements sorted with O(log n) operations and range queries like floor, ceiling, headMap.
• HashMap internals: 16 buckets, load factor 0.75, hash spread with h ^ (h >>> 16), index (n-1) & hash, chains treeify at 8 nodes when the table has 64+ buckets, table doubles on resize. Keys must honour the equals/hashCode contract and should be immutable.
• PriorityQueue is a binary heap: poll gives the smallest, iteration is not sorted.
• Java 21 sequenced collections add getFirst, getLast, addFirst, addLast, removeFirst, removeLast and the live reversed() view to lists, deques, linked and sorted sets and maps.
• List.of/Set.of/Map.of (Java 9) create immutable collections that reject nulls and duplicates; List.copyOf (Java 10) snapshots; Collections.unmodifiableList is a view; Stream.toList() (Java 16) is unmodifiable.
• Comparable defines one natural order inside the class; Comparator defines external orders, composed with comparing, thenComparing, reversed, nullsLast. Never subtract to compare.
• Never remove inside a for-each loop; use removeIf or Iterator.remove(). Concurrent collections have weakly consistent iterators.
• Generics give compile-time type safety: generic classes and methods, bounded types (<T extends Comparable<T>>), wildcards following PECS (? extends to read, ? super to write), and type erasure, which explains why new T(), T[] and instanceof List<String> are impossible.

Next lecture: Lambdas, Functional Interfaces & the Streams API