Java ships a new version every six months. I kept telling myself I'd read the release notes "someday".
Then I found myself in an interview, staring at a switch with pattern matching, and realised I was three versions behind and didn't even know it.
So I built NextPatch.
What it is
A tiny daily habit for working Java developers:
- Read a ~45-second summary of one change between versions, with a before/after example.
- Solve a ~2-minute challenge: fill the blank, fix the bug, order the lines or predict the output.
- Earn XP and keep your streak. Come back tomorrow.
Think language-learning app, but for not going rusty as a developer.
Try one right now (no sign-up)
Since Java 22 you can mark a variable you have to declare but won't use with a single character. Fill in the blank:
int total = 0;
for (Order ❓ : orders) {
total++;
}
Answer
_, the unnamed variable (JEP 456). It says "I need the variable, not its value". It works in loops, in catch (Exception _), in lambdas and in record patterns.
There are three of these on the landing page that you can solve without an account.
What's included
- Paths by version jump: Java 8 → 11, 17 → 21, 21 → 25, with more to come as new versions ship
- Challenge types: fill the blank, multiple choice, fix the bug, order lines, predict the output
- XP, daily streaks, badges, and weekly + global leaderboards
- Content in English, Spanish and Catalan
- Free. No card, no ads, no trial that runs out. The free account is the full account.
A few things I learned building it
Since this is dev.to, here's the part under the hood:
No code sandbox, on purpose. Running untrusted user code safely is a whole product in itself. Instead, every challenge is graded deterministically on the server: token matching, string validation or option checking. The solution is never sent to the client. It keeps grading instant and the infrastructure tiny.
Eating my own dog food on the stack. It runs on Java 25 + Spring Boot 4 with virtual threads turned on (spring.threads.virtual.enabled=true). The workload is almost all I/O, which is exactly where Loom pays off.
Boring architecture, happily. It's a Thymeleaf monolith with server-side sessions (form login + Google OIDC + remember-me), plus a small JSON API called with fetch. No SPA, no JWT for auth. For a solo project that has been a real productivity win.
It runs on a Raspberry Pi. Production sits on a Pi at home, published through a Cloudflare Tunnel. No open ports and no cloud bill so far.
i18n of content is harder than i18n of UI. Translating a challenge must change the words and never its shape: same number of options, same order, same blanks. Otherwise it grades wrong without throwing any error. Lesson learned.
It's in beta
Things may break. If you try it, I'd genuinely love feedback:
- Which Java version jump should I cover next?
- Is 3 minutes a day the right size, or too little?
- Which challenge type do you like most, and which least?
--> NextPatch, free and all features included.
Top comments (4)
The unnamed-variable loop fits the 45-second lesson and two-minute challenge: it's a small syntax change that sticks better when you use it immediately. Deterministic grading keeps the Raspberry Pi setup simple, but the translation constraint sounds fragile-a shifted blank could silently mark a correct answer wrong. I'd give options language-independent IDs and run the same answer cases across English, Spanish, and Catalan before publishing each challenge.
Thanks Marcus, that's the fragile part for sure. Stable IDs + testing the same answers in every language is going on my to-do list. 😄
The stable ID is especially useful when the visible answer text changes but the concept does not. I would include one intentionally wrong answer in each language too; a translated quiz should agree on what to reject, not only on the happy path.
Good point, thanks. In our setup the grading never actually sees the translated text, so rejection ends up being identical by construction. But you made me realize we weren't checking the distractors for meaning drift or duplicate text per language, and we also weren't verifying that the starting code of a fix-the-bug exercise actualy fails. We're adding both checks now, good catch, thks 😉