Checkpoint: Practical Java

This checkpoint ties together the practical-Java track — collectors, virtual threads, the HTTP client, equals/hashCode, immutability, the builder pattern, dependency injection, and serialization — into one combined build challenge.

Learn Checkpoint: Practical Java in our free Java course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Java course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

A recap of eight lessons, a multi-step build challenge (an immutable record assembled by a builder, grouped with collectors, with a correct equals/hashCode), a written checkpoint quiz, and a 10-question timed quiz. If anything here feels shaky, revisit that lesson before moving to the final project.

💡 Analogy: Up to now you've been collecting individual tools — a saw here, a clamp there. A checkpoint is where you build something using several tools at once . The challenge below makes one small program that needs a record (the material), a builder (the jig that assembles it), equals/hashCode (so duplicates don't sneak in), and collectors (to measure and sort the finished pieces). That's how real code feels — patterns combine.

Complete the starter below: finish the record's validation, the nested Builder , and the four stream pipelines. Then compare against the full compiled solution. The expected output is shown in the comments.

A record built by a builder, deduplicated by its generated equals / hashCode , and grouped four ways with Collectors:

Real output (compiled and run with javac 21 ):

Notice how every concept appears: the record gives free equals/hashCode (so the duplicate Apple collapses, leaving 5 distinct), the builder assembles each product with defaults and validation, and collectors compute totals, counts, and the dearest item per category — all in deterministic TreeMap order.

Answer: the record auto-generates equals / hashCode from all components, so two Apples with the same name, category and price are equal and hash to the same bucket — the HashSet treats them as one.

Answer: sorted, deterministic key order. Without it you'd get a HashMap whose printed order is undefined.

Answer: it runs for every way the record is created (including via the builder's build() ), so an invalid Product can never exist.

Answer: submit each HTTP send to Executors.newVirtualThreadPerTaskExecutor() — virtual threads let thousands of blocking calls run concurrently without exhausting OS threads.

Answer: defensively copy it in the compact constructor with tags = List.copyOf(tags) , so neither the caller's list nor the accessor can mutate the record.

Answer: maxBy reduces each group to an Optional<Product> ; the finishing function opt.map(Product::name).orElse("none") turns it into just the name.

You combined records, builders, equals/hashCode and collectors into one working program, and recapped the whole practical track — collectors, virtual threads, the HTTP client, immutability, dependency injection, and serialization. These are the patterns you'll reach for constantly in real Java.

Next up: the Final Project — bring everything together into one substantial application.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary