DEV Community: Nextpatch

5 cambios de Java 21 que deberías estar usando ya

Nextpatch — Sun, 11 Oct 2026 09:04:07 +0000

Si buscas algo sobre Java moderno en español, lo normal es acabar leyendo en inglés: la documentación, los JEP y casi todos los artículos lo están. Así que aquí va uno escrito en castellano desde el principio.

Java 21 salió en septiembre de 2023 y muchos proyectos siguen escribiendo código como si estuvieran en Java 11. Compila igual, pero se pierden cambios que hacen el código más corto y más fácil de leer, y que te pueden preguntar en cualquier entrevista técnica.

Aquí van cinco que puedes empezar a usar el lunes. Cada uno lleva un reto de dos minutos para comprobar que lo tienes claro.

1. Hilos virtuales: escala, no velocidad

Un hilo de plataforma, el Thread de siempre, envuelve un hilo del sistema operativo: es caro de crear y hay pocos. Por eso llevamos años con pools acotados o programación asíncrona.

Java 21 cierra los hilos virtuales (JEP 444). Siguen siendo instancias de java.lang.Thread, pero los planifica la JVM sobre unos pocos hilos del sistema. Cuando uno se bloquea en una operación de E/S del JDK, se desmonta y deja libre su hilo portador para otro.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(task);
}

Lo que más se malinterpreta: no son hilos más rápidos. Lo que mejora es el throughput cuando tienes miles de tareas que pasan casi todo el tiempo esperando (peticiones HTTP, consultas a base de datos). Si tu carga es de CPU, no ganas nada.

Un matiz antes de usarlos en producción con Java 21: dentro de un bloque synchronized el hilo virtual queda anclado (pinning) y bloquea también a su portador. Java 24 lo resolvió con el JEP 491, pero en Java 21 conviene cambiar a ReentrantLock los synchronized que envuelven llamadas de red.

Practícalo: hilos virtuales, escala y no velocidad.

2. Pattern matching en switch

Decidir qué hacer según el tipo de un objeto era una cadena de if ... else if con instanceof. Java 21 cierra el pattern matching para switch (JEP 441), después de cuatro rondas de preview desde Java 17:

static String formatter(Object obj) {
    return switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case String s  -> String.format("String %s", s);
        default        -> obj.toString();
    };
}

El selector puede ser de cualquier tipo de referencia, y cada case lleva un patrón de tipo como los de instanceof. Gana el primer case que encaja, en el orden en que están escritos.

Lo importante es que compara el tipo real del objeto, no su valor: un Object que guarda un Long no entra en case Integer i, aunque el número quepa en un int. Además, el compilador te avisa si un case nunca se puede alcanzar porque otro anterior ya lo cubre.

Practícalo: el switch deja de comparar solo constantes.

3. case null y guardas when

Antes, un switch con selector null lanzaba NullPointerException, así que la comprobación vivía fuera, en un if. Ahora puedes meterla dentro con case null, y añadir condiciones a cada caso con when:

switch (s) {
    case null -> System.out.println("Oops!");
    case String v when v.equalsIgnoreCase("YES") -> System.out.println("You got it");
    case String v -> System.out.println("Sorry?");
}

Una guarda solo aplica si el patrón encaja y la condición es cierta. Si no, el switch sigue probando los siguientes case. El orden importa: el caso con guarda va antes que el general, porque al revés el general lo taparía y el compilador daría error.

Solo los patrones admiten guardas: case "hola" when ... no compila, porque una constante no es un patrón.

¿Y qué pasa con el default cuando llega un null? Te lo dejo para el reto del final.

4. Record patterns

El pattern matching de instanceof te ahorra el cast, pero luego sigues escribiendo p.x() y p.y(). Java 21 cierra los record patterns (JEP 440), que sacan los componentes en el propio patrón:

record Point(int x, int y) {}

if (obj instanceof Point(int x, int y)) {
    System.out.println(x + y);
}

El patrón comprueba el tipo y, si encaja, llama a los accesores del record. Los nombres de las variables no tienen que coincidir con los de los componentes, puedes usar var en cada posición y funcionan igual en instanceof y en los case de un switch. Los patrones se pueden anidar: el conjunto solo encaja si encajan todos los subpatrones, y si alguno falla, no hay excepción, simplemente no entra en esa rama.

Combinado con un switch sobre una jerarquía sealed, tratas cada forma de tus datos en una línea, sin casts y con el compilador comprobando que no se te escapa ningún caso.

Practícalo: deconstruir un record dentro del patrón.

5. Colecciones secuenciadas

Pedir el primer y el último elemento dependía del tipo: list.get(0) y list.get(list.size() - 1) en una lista, deque.getFirst() en un Deque, sortedSet.first() en un SortedSet... y en un LinkedHashSet no había forma de sacar el último sin recorrerlo entero.

El JEP 431 añade SequencedCollection, SequencedSet y SequencedMap para las colecciones con un orden definido, y las encaja en la jerarquía que ya existía:

String primero = lista.getFirst();
String ultimo = lista.getLast();
String ultimoDelSet = linkedHashSet.getLast();

Además de getFirst y getLast llegan addFirst, addLast, removeFirst, removeLast y reversed(). Ojo con este último: no copia la colección, devuelve una vista en orden inverso. Y con la colección vacía, getFirst() y getLast() lanzan NoSuchElementException, como ya hacía Deque.

Practícalo: getFirst, getLast y reversed.

Mini reto: el null y el default

Este código tiene un default, pero no tiene case null:

static String describe(Object o) {
    return switch (o) {
        case String s -> "texto";
        case Integer i -> "número";
        default -> "otra cosa";
    };
}

describe(null);

¿Qué pasa al llamar a describe(null)? ¿Devuelve "otra cosa", lanza una excepción o ni siquiera compila?

Responde en el reto de case null y guardas when. No hace falta cuenta y se resuelve en un momento.

Escribo estos artículos mientras construyo NextPatch, un hábito diario para desarrolladores Java: un resumen de 45 segundos de un cambio entre versiones y un reto de 2 minutos, también en español. ¿Qué novedad de Java 21 has adoptado de verdad en el trabajo y cuál sigues ignorando? Cuéntamelo en los comentarios.

5 Java 21 changes you should already be using

Nextpatch — Thu, 08 Oct 2026 20:45:00 +0000

ava 21 came out in September 2023, and plenty of projects still write code as if they were on Java 11. It compiles just the same, but they miss changes that make code shorter and easier to read, and that can come up in any technical interview.

Here are five you can start using on Monday. Each one comes with a two-minute challenge to check you've got it.

1. Virtual threads: scale, not speed

A platform thread, the Thread we've always had, wraps an operating system thread: it's expensive to create and there aren't many of them. That's why we've spent years with bounded pools or asynchronous code.

Java 21 finalises virtual threads (JEP 444). They are still instances of java.lang.Thread, but the JVM schedules them over a few OS threads. When one blocks on a JDK I/O operation, it unmounts and frees its carrier thread for another one.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(task);
}

The most misunderstood part: they are not faster threads. What improves is throughput when you have thousands of tasks that spend most of their time waiting (HTTP requests, database queries). If your workload is CPU-bound, you gain nothing.

One caveat before using them in production on Java 21: inside a synchronized block the virtual thread gets pinned and blocks its carrier too. Java 24 fixed that with JEP 491, but on Java 21 it's worth switching the synchronized blocks that wrap network calls to a ReentrantLock.

Practise it: virtual threads, scale not speed.

2. Pattern matching for switch

Deciding what to do based on an object's type used to be a chain of if ... else if with instanceof. Java 21 finalises pattern matching for switch (JEP 441), after four preview rounds starting in Java 17:

static String formatter(Object obj) {
    return switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case String s  -> String.format("String %s", s);
        default        -> obj.toString();
    };
}

The selector can be any reference type, and each case takes a type pattern just like instanceof. The first case that matches wins, in the order they're written.

The key point is that it compares the object's actual type, not its value: an Object holding a Long doesn't match case Integer i, even if the number fits in an int. On top of that, the compiler tells you when a case can never be reached because an earlier one already covers it.

Practise it: switch stops comparing only constants.

3. case null and when guards

A switch with a null selector used to throw NullPointerException, so the check lived outside it, in an if. Now you can bring it inside with case null, and add conditions to each case with when:

switch (s) {
    case null -> System.out.println("Oops!");
    case String v when v.equalsIgnoreCase("YES") -> System.out.println("You got it");
    case String v -> System.out.println("Sorry?");
}

A guard only applies if the pattern matches and the condition is true. If not, the switch keeps trying the following cases. Order matters: the guarded case goes before the general one, because the other way round the general one would hide it and the compiler would report an error.

Only patterns take guards: case "hello" when ... doesn't compile, because a constant isn't a pattern.

And what happens to default when a null comes in? I'll leave that for the challenge at the end.

4. Record patterns

Pattern matching for instanceof saves you the cast, but you still end up writing p.x() and p.y(). Java 21 finalises record patterns (JEP 440), which pull the components out in the pattern itself:

record Point(int x, int y) {}

if (obj instanceof Point(int x, int y)) {
    System.out.println(x + y);
}

The pattern checks the type and, if it matches, calls the record's accessors. The variable names don't have to match the component names, you can use var in each position, and they work the same in instanceof and in the case labels of a switch. Patterns can be nested: the whole thing only matches if all the subpatterns match, and if one fails there's no exception, the branch just doesn't run.

Combined with a switch over a sealed hierarchy, you handle each shape of your data in one line, with no casts, and the compiler checks that no case slips through.

Practise it: deconstructing a record inside the pattern.

5. Sequenced collections

Getting the first and last element depended on the type: list.get(0) and list.get(list.size() - 1) on a list, deque.getFirst() on a Deque, sortedSet.first() on a SortedSet... and on a LinkedHashSet there was no way to get the last one without walking through the whole set.

JEP 431 adds SequencedCollection, SequencedSet and SequencedMap for collections with a defined order, and fits them into the existing hierarchy:

String first = list.getFirst();
String last = list.getLast();
String lastInSet = linkedHashSet.getLast();

Besides getFirst and getLast you get addFirst, addLast, removeFirst, removeLast and reversed(). Careful with that last one: it doesn't copy the collection, it returns a view in reverse order. And on an empty collection, getFirst() and getLast() throw NoSuchElementException, just as Deque already did.

Practise it: getFirst, getLast and reversed.

Mini challenge: null and default

This code has a default, but no case null:

static String describe(Object o) {
    return switch (o) {
        case String s -> "text";
        case Integer i -> "number";
        default -> "something else";
    };
}

describe(null);

What happens when you call describe(null)? Does it return "something else", throw an exception, or not even compile?

Answer it in the case null and when guards challenge. No account needed, and it only takes a moment.

I write these while building NextPatch, a daily habit for Java developers: a 45-second summary of one change between versions and a 2-minute challenge. Which Java 21 feature did you actually adopt at work, and which one are you still ignoring? Tell me in the comments.

I made every Java challenge in my app a public link you can solve without signing up. Roast the setup?

Nextpatch — Sun, 04 Oct 2026 09:59:26 +0000

A few weeks ago I posted about
NextPatch,
a small daily habit for Java developers: a 45-second summary of one change between
versions, then a 2-minute challenge.

Thanks for the feedback on that one. Re-reading the post afterwards, one thing bothered
me: every link ended on a login screen. I was asking people to create an account
before they'd seen a single challenge. I wouldn't do that for a quiz app either.

So I spent the last few weeks on one idea:

Every challenge should be a link you can share, open on your phone and solve in
under 30 seconds, without an account.

Here's how I built it. I'd really like your opinion on the design, and on how it
feels if you try one.

-> Today's challenge: nextpatch.dev/reto-de-hoy
-> All of them: nextpatch.dev/retos

1. Every challenge gets a URL that never changes

Challenges don't have titles, so the slug is built from the lesson title plus the
challenge's position in it:

/reto/var-adios-a-repetir-el-tipo-2

On a collision it appends -2, -3... The important part is that the slug is set
when the challenge is created and never recalculated, even if someone renames the
lesson or reorders it. A link someone shared on WhatsApp six months ago still has to
work.

Production already had ~560 challenges, so a startup runner fills in the missing slugs.
It's idempotent: once every challenge has one, it does nothing.

(Yes, the URLs are in Spanish. That's where the project started. Is it weird for you
as an English speaker? Honest question.)

2. Grading without an account, and without leaking the answer

The page calls two anonymous endpoints:

GET  /api/v1/public/challenges/{slug}        → the challenge, no solution
POST /api/v1/public/challenges/{slug}/check  → { answer } → { correct, explanation }

Each challenge stores a payload (what you see) and a solution (what the server
checks), and the solution is never serialized. Grading is deterministic: the server
compares option ids, tokens or line orders. No user code is ever executed. No
sandbox, no containers, so it all runs fine on a small home server.

The anonymous check doesn't save anything and doesn't give XP. It just tells you
whether you were right and why.

3. Solve first, sign up later, and keep the credit

This is the part I'm least sure about. I'd love your take.

If you get it right without being logged in, the server sets a cookie:

np_reto = slug.epochSeconds.HMAC-SHA256

It's signed so you can't forge "I solved 50 challenges", it's HttpOnly and Secure,
and it expires after 24 hours. Only after you get it right does the page show "Keep
your streak: create an account". It never asks before.

If you sign up or log in while that cookie is alive, the challenge is claimed: it
counts as solved, you get its XP, and today counts as day 1 of your streak. Claiming is
idempotent: if you'd already solved it, nothing happens. And it doesn't unlock the
lesson. You still walk the path in order.

Why a cookie and not a row in the database? The server doesn't create any record for
anonymous visitors. Your progress only exists on the server once you decide to sign up.

4. A "challenge of the day" that's the same for everyone

/reto-de-hoy redirects to one challenge, the same for everyone that day. It's picked
deterministically from the date:

static String choose(LocalDate day, List<Candidate> candidates) {
    var easy = candidates.stream()
            .filter(c -> c.difficulty() <= 2 && QUICK_TYPES.contains(c.type()))
            .toList();
    var pool = easy.isEmpty() ? candidates : easy;
    return pool.get(Math.floorMod(scramble(day.toEpochDay()), pool.size())).slug();
}

Two details:

It only picks easy, quick types (multiple choice, fill in the blank, predict the output). The daily challenge is a first impression, not a boss fight.
scramble is the SplitMix64 finalizer. With the raw day number, consecutive days would land on neighbouring challenges from the same lesson. Mixing the bits spreads them across the whole catalog.

The choice is cached in memory until the date changes. Publishing new content
mid-morning doesn't change today's challenge for someone who has already seen it.

5. Link previews drawn with Java2D

A shared link is only as good as its preview. Every challenge has an Open Graph image
(1200×630): the code with syntax highlighting and the blank drawn as an empty box.

I didn't want a headless browser on a small server, so it's plain Java2D with the
fonts bundled in the jar. Two decisions I like:

The renderer only gets the same DTO as the public page, so the answer can't end up in the image.
The image URL carries a hash of the challenge's content. If the challenge changes, the URL changes, and LinkedIn, WhatsApp and the CDN fetch the new image. If it doesn't, the image is drawn once and served from cache.

6. The test I set before promoting anything

I set myself one rule before posting anywhere: someone who opens a shared link on their
phone, with no account, solves a challenge in under 30 seconds. The first time I tried,
on mobile, the challenge started about 1,230 px down the page, below the theory.
Now it's right under the title and the explanation is folded behind "Why? See the
explanation". My last run took 3.6 seconds from tapping the link to "Correct!".

That was me, though, and I know where everything is. That's why I'm writing this.

What I'd love from you

On the design:

Solve-first, sign-up-later with a signed cookie: would you do it differently?
Slugs that never change, even when the title does: right call, or will it bite me?
Java2D for link previews instead of a headless browser: clever or cursed?

On the experience (if you have 2 minutes):

Open today's challenge on your phone.
Solve it, or fail it. Both are useful to me.
Tell me in the comments: how long did it take, what slowed you down, and did the explanation help?

Anything that felt slow, confusing or ugly is exactly what I want to hear.
Thanks for reading :)

I got tired of always being three Java versions behind, so I built a little game to fix it

Nextpatch — Fri, 25 Sep 2026 21:48:45 +0000

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.