Rung 4 — Modern-Java Refactor Case Study

Target month: Shipped by end of M6 = end of December 2026 (started in M5) Calendar deadline: December 31, 2026 Phase alignment: Phase 03 (Design Patterns) → Phase 04 (Generics/Streams/Functional) Signal level: Design taste → proves you can look at 15-year-old Java and see what’s wrong — the exact skill the M13 pitch is built on

What It Is

A public repo + a blog post that together tell the story of taking a real, ugly, Java-6-or-7-era codebase and refactoring it into idiomatic Java 21 — with the tests still green at every commit.

Two deliverables, tightly coupled:

  1. The repo — github.com/RaghulR2003/java6-to-21-refactor with:

    • A before/ directory containing the untouched original code

    • An after/ directory containing your refactored version

    • A commit history that walks through the refactor in ~15-25 small commits, each a single named transformation (e.g., "replace anonymous Comparator with lambda", "convert getters/setters/equals/hashCode to record", "replace visitor pattern with sealed interface + pattern matching")

    • The same test suite passing in both before/ and after/

  2. The blog post — published on Hashnode (primary) and cross-posted to dev.to and LinkedIn (canonical link back to Hashnode). Title: “Refactoring a Java 6 codebase to Java 21 — 15 patterns, one weekend, one repo.”

The blog post walks through the 10-12 most instructive transformations with side-by-side code snippets. Each snippet block has three parts: before, after, why.

What to refactor

You need a real Java 6/7/8 codebase. Options, in order of preference:

  1. Take an old Apache Commons or Spring sample project from ~2010-2013. There are hundreds. commons-lang3 early versions, old Spring PetClinic forks, guava-libraries samples.

  2. Build your own “legacy” starter. Write a 500-line Java 6-styled inventory management CLI. This is easier because you control the pathology. Downside: it feels contrived.

  3. Take an old GitHub project you personally wrote. If you have a Java project from college, this is the strongest option — the story is personal.

Recommendation: Option 3 if you have one, otherwise Option 1. Option 2 is a fallback only.

The refactor targets (aim for at least 12 of these)

  • POJO with getters/setters/equals/hashCode → record

  • Anonymous inner class → lambda / method reference

  • if-else if-else if type dispatch → switch expression with pattern matching

  • Type hierarchy with instanceof chains → sealed interface + pattern matching

  • Verbose null-check chains → Optional / Optional.map

  • Explicit iterator loops over collections → streams (only where readability improves)

  • Explicit Iterator implementation → Iterable + stream()

  • new ArrayList<Foo>() → var (only where the type is obvious)

  • Manual thread + synchronized → ExecutorService or virtual threads

  • Verbose try-catch-finally with resource cleanup → try-with-resources

  • Vector / Hashtable / Stack → modern collection + Collections.synchronizedX or concurrent collection

  • String concatenation in loops → StringBuilder or String.join

  • Ad-hoc date arithmetic on java.util.Date → java.time

  • Reflection-based property access → records + accessors

  • Visitor pattern → sealed interface + pattern matching switch (this is the money shot)

Where To Publish

  • Repo: github.com/RaghulR2003/java6-to-21-refactor — public, pinned by end of M6

  • Blog (canonical): Hashnode at raghulr2003.hashnode.dev (or your handle)

  • Cross-post: dev.to with canonical_url pointing to Hashnode. Cross-post to Medium if you’re on it.

  • LinkedIn: Long-form post (2000+ chars) with the money-shot before/after code block as the image, linking to the full Hashnode post

  • Announcement thread: Twitter/X and Bluesky on the day the post goes live. Three tweets max: hook, best snippet, link.

Acceptance Criteria

  • Repo exists, public, pinned

  • before/ and after/ directories, same test suite passing in both

  • At least 12 distinct refactoring transformations applied, each as its own commit with a descriptive commit message

  • Commit history is linear and reads as a walkthrough (no merge from main noise, no wip commits)

  • Blog post published on Hashnode with 10+ before/after snippets, each with a why paragraph

  • Blog post cross-posted to dev.to with canonical link to Hashnode

  • LinkedIn long-form post published, links to blog post, includes at least one code image

  • Repo README has a summary table: transformation name, files affected, LoC delta, commit link

  • Both before/ and after/ compile clean and tests pass in CI (matrix build: JDK 8 for before, JDK 21 for after)

  • Blog post attracts real signal within 30 days of posting: 10+ reactions on Hashnode/dev.to OR 20+ reactions on LinkedIn (this is the first rung where audience response matters)

Signal It Sends

  • You can read legacy Java. The Indian MNC job market has more Java 8 codebases than Java 21 codebases. Reading old Java without wincing is a real skill — half the work at a Zoho / TCS / Infosys is exactly this.

  • You can see the improvement. Junior engineers can refactor by rote. Senior engineers can articulate why each change makes the code better. The blog post is the artifact that proves you can articulate.

  • You can write. Technical writing is undervalued and undersupplied. A well-structured blog post that circulates is worth more career-signal than another repo.

  • You know Java 21 idioms. Records, sealed types, pattern matching, virtual threads — by demonstrating them in refactors of real code (not toy examples), you prove you’d bring them to a real codebase.

Common Failure Modes

  • Refactoring a codebase you don’t understand. If you can’t read the before/ code confidently, you’ll refactor it into subtly-broken after/ code. Pick a codebase you can hold in your head.

  • The Big-Bang Commit. You do the whole refactor in one branch, then squash-merge. The story is dead. Commit each transformation atomically. The commit history is half the artifact.

  • Tests don’t run in before/. If you can’t get the original tests running under JDK 8, the whole comparison collapses. Verify green tests in before/ before you touch anything.

  • Refactoring for the sake of refactoring. Not every anonymous inner class needs to become a lambda — sometimes the lambda is worse. Include one or two transformations you chose not to do with an explanation why. That’s a senior-signal move.

  • The blog post never ships. The repo is 90% of the value; the blog post is 10% of the effort. Do not skip it. This is the rung where you start being readable, not just findable.

  • Publishing on Medium as the canonical. Medium’s paywall is a bad fit for a developer audience. Hashnode is free and gaining traction in India. Use it as canonical.

Time Estimate

  • Selecting a codebase + getting tests green in before/: ~6 hours

  • 12-15 refactor commits, each carefully: 1-2 hours per commit × 14 = ~20 hours

  • README + commit-history polish: ~3 hours

  • Blog post: outline, draft, edit, code snippets: ~10 hours (do not underestimate)

  • Cross-posting, LinkedIn write-up, images: ~3 hours

  • CI matrix build: ~2 hours

  • Total: ~44 hours over 5-6 weeks

Prerequisites

  • Rungs 1, 2, 3 shipped (you can write, read, and reason about Java without friction)

  • Comfort with modern Java: records, sealed classes, pattern matching, streams, var, Optional, java.time. If Phase 03 and Phase 04 files aren’t done yet, do them first.

  • A Hashnode account with your custom subdomain

  • Basic markdown blogging fluency (this can be practiced on the Rung 1 optional dev.to post)

Stretch Goals (Optional)

  1. Publish a follow-up post: “5 refactors I didn’t do, and why.” The negative-space post is more senior-signal than the primary post. “When not to refactor” is a topic underserved in the current Java blog market.

  2. Record a 15-minute video walkthrough of the money-shot commit (probably the sealed-interface / visitor-pattern one). Upload to YouTube, embed in the blog. Adds a personal-brand dimension that most Java devs don’t have.

  3. Submit the blog post to the This Week in Java newsletter and Reddit’s r/java. If it gets traction, it becomes evergreen recruiter-bait.

Return to README.md · Next: 05_rung5_concurrency_playground.md