The Registry

Whether you can choose types on purpose instead of typing int everywhere. Also this is the first version of a program you will keep rebuilding for the rest of the course, and it is meant to look primitive right now.

Whether you can recognise the situation where double is the wrong tool. This exact bug has cost real companies real money, and it looks completely innocent right up until an auditor finds it.

Whether you can use bitwise operators for what they are really for, which is packing many yes-or-no answers into one number. This is how permissions, feature switches and file modes are stored everywhere.

Whether you can turn a set of written rules into readable conditional code. Anyone can write nested ifs. Writing them so a human can check them against the rules is the actual skill.

Whether you can drive a loop from user input rather than a fixed count, and whether you pick the loop shape that fits. This is the first Registry program that keeps running until the user says stop.

Whether you can hold several parallel facts about many units using only arrays. It works, and it is clumsy, and feeling that clumsiness now is what makes objects land properly in Phase VI.

Whether you can build the core strategy used by array-backed lists by separating size from capacity, allocate a larger backing array when full, and copy. This exercise chooses doubling; ArrayList does not promise that exact growth rule.

Whether you can restructure a long main into named pieces, and whether you use overloading where it genuinely helps rather than everywhere you can.

Whether you can see what a class buys you, by rewriting code you already wrote badly. The Section 4.1 sorting bug should become impossible, and you should be able to say exactly why.

Whether you can put validation in exactly one place. Three constructors with copied setup is three places a rule can be forgotten, and this exercise makes you feel that by adding a rule afterwards.

Whether you can identify a mutable reference crossing a class boundary and apply defensive copying on both input and output.

Whether you can choose class-level or per-instance ownership for each member and predict class initialization separately from object construction.

Whether you can design a small hierarchy where the shared parts genuinely belong in the parent. Putting too much in the parent is as wrong as putting too little, and both look fine until you add a fourth type.

Whether you can recognise unboxing hiding in an innocent looking line. The stack trace points at code with no visible method call, which makes this one of the more confusing failures a beginner meets.

Whether you can read structured data from a file, handle the bad rows, and close the file properly. Every real program does this, and the bad rows are always the interesting part.

Whether you can build a nested immutable structure, where a class holds other immutable objects. This is the shape you actually want in real code, and it is where the compounding benefit shows.

Whether you can decide what identity means for a real domain object rather than mechanically including every field. This is a design decision, not a mechanical one, and different answers are defensible.

Whether you can move a rule out of scattered if statements and into the type it belongs to. This is where enums stop being a nicer int and start being genuinely useful.

Whether you can put the whole phase together. Interfaces, defaults, a marker, a functional interface and lambdas, in one small design that hangs together.

Whether you can build the design String uses, including the pool. It is the four immutability steps from Section 8.2 plus a cache, and building it makes String stop being magic.

Whether you reach for a StringBuilder when building text in a loop. This is the shape the mistake takes in real code, where the loop count comes from data rather than a literal.

Whether you can choose between T, ? extends, ? super and plain ? for a real API. Every one of the five methods here has a right answer, and a reason.

Whether you can replace hand-written array code with the framework and see what you deleted. The old version worked, and this is how much of it was scaffolding.

Whether you can implement Iterable. One method, and your class joins the same loop syntax as every collection in Java.

Whether you can pick an implementation from the shape of the work rather than from habit. Four workloads, and the right answer is not the same one every time.

Whether you can produce the worst bug in the framework and then design it out. You made it happen in Section 8.3. This is it in the place it actually occurs.

Whether you know what sorted order buys you. Nearest-below and range queries are impossible on a hash map, and they are exactly what some problems need.

Whether you can order a queue by something other than arrival. This is where PriorityQueue first needs to be told how to compare your own objects.

Whether you can decide what belongs as a natural order and what belongs as a comparator. It is a design choice, and putting the wrong one in the class affects every TreeSet that ever holds it.