← Java Toolkit · guided lesson
Java Toolkit & Collections
the story
The Collections Framework
Every tool here exists because something was too slow or broke without it. Here is what.
Early Java had arrays, Vector and Hashtable, with no shared interface between them. JDK 1.2 (renamed Java 2, shipped December 1998) added the Collections Framework: interfaces like List, Set and Map, plus ready-made implementations behind them. Joshua Bloch led its design. The old Vector and Hashtable were retrofitted to fit the new interfaces.
the problem it solved
Every library invented its own containers, so code couldn't pass collections around, or swap a slow implementation for a faster one without a rewrite.
why it matters: without it
Every solution would start with a hand-written hash table or heap, and every library would speak its own container dialect.
sources: Collections Framework Overview (Oracle) ↗ · OpenJDK source: java.util.Collection (@author Josh Bloch, Neal Gafter; @since 1.2) ↗ · Joshua Bloch, author bio (InformIT) ↗ · LWN, 10 Dec 1998: JDK 1.2 ships as the Java 2 Platform ↗
also in this chapter: ArrayList (dynamic array) · HashMap & HashSet (hash table) · ArrayDeque (ring buffer) · PriorityQueue (binary heap) · TreeMap & TreeSet (red-black tree) · Autoboxing & the Integer cache
the idea
The idea in 30 seconds
Most interview solutions are 80% choosing the right container: ArrayList, ArrayDeque, HashMap/HashSet, TreeMap/TreeSet, PriorityQueue.
Each one is a data structure you'll meet later in the course. The JDK already wrote it for you. Know what's inside, and you know what each call costs.
A few traps (Integer ==, a - b comparators, remove(int) vs remove(Object)) cause most "it works on my example" bugs.
picture this
java.util is like the tools already installed on your laptop. Nobody writes a text editor before taking notes, but you do need to know when to open Notepad and when to open Excel. Same here: pick the container whose strengths match the job.
watch it
Inside ArrayList: growing by 1.5×
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
Inside ArrayList: growing by 1.5×
Adds are cheap writes. When the array is full, Java allocates about 1.5× the slots and copies everything. That's rare enough that add stays amortized O(1).
On this screen ← / → step the simulation. Use the buttons below to move through the lesson.
watch it
Inside HashMap: buckets, collisions, resizing
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
Inside HashMap: buckets, collisions, resizing
Each key is hashed to a bucket. Watch a collision form a chain, then the table double at load factor 0.75.
On this screen ← / → step the simulation. Use the buttons below to move through the lesson.
key idea 1 of 8
Read it once. Say it out loud once. Bas.
The map: List (ArrayList) for indexed sequences · Deque (ArrayDeque) for stacks and queues · Set/Map (Hash, LinkedHash, Tree*) for membership and lookup · PriorityQueue for "give me the smallest next".
key idea 2 of 8
Read it once. Say it out loud once. Bas.
ArrayList is a growable array: when full it allocates about 1.5× the slots and copies everything. That's rare, so add is amortized O(1). But add(0, x) and remove(0) shift every element: O(n).
key idea 3 of 8
Read it once. Say it out loud once. Bas.
Hash vs Linked vs Tree: HashMap is O(1) average with no order · LinkedHashMap is O(1) average and keeps insertion order · TreeMap is O(log n) with sorted keys plus floor/ceiling queries.
key idea 4 of 8
Read it once. Say it out loud once. Bas.
Use `ArrayDeque`, not `Stack` or `LinkedList`, for stacks and queues. Stack is a synchronized legacy class; ArrayDeque is a fast ring buffer.
key idea 5 of 8
Read it once. Say it out loud once. Bas.
int vs Integer: collections hold objects, so an int is autoboxed. == on two Integers compares references. It only seems to work for −128..127 (the Integer cache). Use equals, or unbox.
key idea 6 of 8
Read it once. Say it out loud once. Bas.
Order objects with comparators: Integer.compare(a, b) or Comparator.comparingInt(...), never a - b (overflow). Chain with thenComparing, flip with reversed().
key idea 7 of 8
Read it once. Say it out loud once. Bas.
This chapter is the Collections Framework. Strings and StringBuilder live in Java arrays & strings, overflow in Java memory, fast I/O in Java I/O & debugging, generics and records in Java OOP.
key idea 8 of 8
Read it once. Say it out loud once. Bas.
Utilities you'll use daily: Arrays.sort/fill/toString/asList/copyOf, Collections.sort/reverse/max, List.of, Map.getOrDefault/merge/computeIfAbsent.
spot the pattern
When you see this, think this
"Most recent", matching brackets, undo, monotonic stack
ArrayDeque as a stack
Level-by-level, BFS, "process in arrival order"
ArrayDeque as a queue
Frequencies, "how many times", grouping by a key
HashMap (merge / computeIfAbsent) or int[26]
"Closest value ≤ x", sorted keys while inserting, calendar/booking
TreeMap / TreeSet floor & ceiling
+3 more signals on the chapter page
watch out
A trap or two
Many wrong answers in interviews come from small slips like these, not from the hard part.
- Comparing
IntegerorStringvalues with==: works for small numbers and literals, fails in hidden tests. int c = map.get(key)when the key may be absent → NullPointerException from unboxing.
quick check
One question. No pressure.
Integer a = 128, b = 128; On a default JVM, what is a == b?
now try
Your first real problem
You know enough to try this one. Stuck? Use the hints; that is what they are for.
Valid Anagram
Pick the container for the alphabet: int[26] for lowercase letters, HashMap<Character, Integer> for Unicode.
recall
Flip a few cards
Answer in your head first, then flip. Grade yourself honestly; the schedule brings back what you forget.
Why use ArrayDeque instead of Stack for a stack?
Question 1: Why use ArrayDeque instead of Stack for a stack?
done
Lesson complete
Chalo, that is the core. The full chapter has the rest: cost tables, Java details and more problems.