DEV Community: Felipe Stanzani

Project Loom: Java's Virtual Threads – From Nightmares to Modern Concurrency Bliss

Felipe Stanzani — Wed, 01 Apr 2026 20:21:49 +0000

In 2006, I worked on a large logistics system for transporting wood for pulp production. One of the most critical modules managed the entry and exit of trucks from a storage yard. We implemented it using Threads in Delphi 7. The debugging process was an absolute nightmare.

Hundreds of trucks arriving and leaving, each one triggering database checks, sensor readings, queue management, and synchronization logic. Every thread was a heavyweight OS thread. Memory usage skyrocketed, context switching killed performance, and when something went wrong (which happened constantly), the debugger would freeze or show you a stack trace that made zero sense because the threads were all fighting for the same resources.

Sound familiar?

That exact pain — the same pain Java developers have felt for 30 years with regular Thread objects and ExecutorService backed by platform threads — is what Project Loom was created to eliminate.

Today, with Java 21+ (and fully mature in 2026), Virtual Threads are production-ready and change the game completely.

Let’s demystify Project Loom and see, with real Java code, why Virtual Threads are not just “better threads” — they are a completely different beast.

The Problem with Traditional (Platform) Threads

Since Java 1.0, every new Thread() or thread from a ThreadPoolExecutor is a platform thread:

It maps one-to-one to an OS thread.
It consumes ~1 MB of stack space (configurable, but rarely less).
Creating thousands of them is expensive and risky.
Blocking operations (I/O, sleep(), database calls, HTTP requests) block the entire OS thread.
Context switching is handled by the operating system (expensive).

In the 2006 Delphi system, we could barely handle a few hundred concurrent trucks before the server started thrashing. The same limitation existed in Java until Project Loom.

Classic Platform Thread Example (The Old Way)

Here’s how we used to handle concurrent truck processing in Java (pre-Loom):

* All examples are in Java 25, you MUST enable preview features to execute them.

// OLD STYLE - Platform Threads
public class TruckYardPlatformThreads {

    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(200); // Limited by OS

        for (int i = 0; i < 10_000; i++) {  // Imagine 10,000 trucks arriving
            final int truckId = i;
            executor.submit(() -> processTruck(truckId));
        }

        executor.shutdown();
    }

    private static void processTruck(int truckId) {
        try {
            System.out.println("Truck #" + truckId + " entering yard [Thread: "
                               + Thread.currentThread() + "]");

            // Simulate blocking I/O (database, sensor, loading/unloading)
            Thread.sleep(1000);  // This BLOCKS an entire OS thread!

            System.out.println("Truck #" + truckId + " leaving yard");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Problems with this code:

Maximum practical concurrency: ~200–500 threads on most servers.
Memory usage: 200 threads × 1 MB stack = 200 MB just for stacks.
Debugging deadlocks or race conditions? Good luck.

Enter Project Loom and Virtual Threads

Project Loom (started in 2017) introduced Virtual Threads — lightweight threads managed entirely by the JVM, not the OS.
Key differences:

Feature	Platform Threads (Old)	Virtual Threads (Loom)
Mapping	1:1 with OS thread	Many:1 with carrier (platform) thread
Stack size	~1 MB (fixed)	"A few KB (dynamic, grows as needed)"
Creation cost	Expensive	Extremely cheap
Maximum practical count	Thousands	Millions
Blocking behavior	Blocks OS thread	Does not block carrier thread
Scheduling	OS scheduler	JVM scheduler (work-stealing)
Debugging experience	Same as before	Identical to platform threads

Virtual threads are not a new abstraction like coroutines or reactive streams. They are real Thread objects — you can use Thread.currentThread(), synchronized, locks, ThreadLocal (though ScopedValue is preferred now), and they behave exactly like the threads you already know.

The magic is under the hood: when a virtual thread blocks (e.g., sleep(), I/O, waiting for a lock), the JVM unmounts it from its carrier thread and mounts another virtual thread. The carrier thread (a real OS thread) never blocks.

Creating Virtual Threads – The New Way

// NEW STYLE - Virtual Threads (Java 21+)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1_000_000; i++) {  // ONE MILLION trucks? No problem!
        final int truckId = i;
        executor.submit(() -> processTruck(truckId));
    }
}

Blocking calls like Thread.sleep(), database queries, or HTTP requests no longer waste carrier threads.

Structured Concurrency (The Missing Piece)

Project Loom also introduced Structured Concurrency (via StructuredTaskScope), which makes concurrent code safer and more readable.

Old way (fire-and-forget):

// OLD STYLE - Fire-and-forget with platform threads
// Hard to manage lifecycle, cancellation, and errors
for (int i = 0; i < 5; i++) {
    new Thread(() -> {
        try {
            processTruck(i);
        } catch (Exception e) {
            // Error handling is scattered and unreliable
            e.printStackTrace();
        }
    }).start();
}
// No guarantee that threads will finish, no easy way to wait or cancel

This approach often leads to thread leaks, orphaned tasks, and difficult debugging — the same issues I faced 20 years ago in Delphi.

New way with Structured Concurrency:

// NEW STYLE - Structured Concurrency with Virtual Threads
private static String processTruckWithResult(int truckId) throws InterruptedException {
    System.out.println("Truck #" + truckId + " entering yard [Virtual Thread: "
                       + Thread.currentThread() + "]");

    // Simulate blocking work (DB, sensor, etc.)
    Thread.sleep(1000);

    String result = "Truck #" + truckId + " processed successfully";
    return result;
}

public static void main(String[] args) throws InterruptedException {
    try (var scope = StructuredTaskScope.open(
            StructuredTaskScope.Joiner.allSuccessfulOrThrow())) {
        List<StructuredTaskScope.Subtask<String>> subtasks = new ArrayList<>();

        for (int i = 0; i < 5; i++) {
            final int truckId = i;
            subtasks.add(scope.fork(() -> processTruckWithResult(truckId)));
        }

        scope.join(); // Wait for all subtasks

        for (var subtask : subtasks) {
            // Results are available and exceptions are propagated cleanly
            System.out.println(subtask.get());
        }
    }
    // Scope automatically shuts down and cleans up all subtasks
}

Benefits:

Tasks are confined to a lexical scope (like try-with-resources for threads).
If one task fails, remaining tasks are cancelled automatically.
No thread leaks.
Clear ownership and predictable lifecycle.

Additional Loom Features You Should Know

ScopedValue (modern, safer replacement for ThreadLocal in many cases).
Excellent backward compatibility — most existing thread-based code works with virtual threads with zero or minimal changes.

When Should You Use Virtual Threads?

Use Virtual Threads when:

Your application is I/O bound (web services, APIs, databases, logistics systems).
You need high concurrency with simple code.

Use Platform Threads (or combine) when:

Pure CPU-bound heavy computation.

Final Thoughts

The 2006 logistics system I worked on would have been radically simpler and more reliable with Virtual Threads and Structured Concurrency. No more thread pool tuning nightmares. No more “out of threads” errors at 3 AM.

Project Loom delivers scalable concurrency without forcing you to abandon the familiar threaded programming model.

If you’re still managing fixed thread pools in 2026… it’s time to upgrade.

Have you migrated any production systems to Virtual Threads yet? What was your experience?

Drop your thoughts in the comments below. I’ll see you in the next post where we’ll explore Structured Concurrency and Scoped Values in much more depth.
Until then — keep those memory leaks under control. 🚚

Originally posted on my blog, Memory Leak

Java 26: Pattern Matching Finally Reaches Primitive Types

Felipe Stanzani — Thu, 19 Mar 2026 18:50:27 +0000

Java has been evolving pattern matching for a while now. We got it for instanceof, then for switch, then for records. Each release pushed the idea a bit further. But there was always an odd limitation:

Pattern matching worked great — as long as you stayed in the world of objects.

Primitive types? Not invited.

With Java 23, that gap is finally gone (as the first preview of this feature). This isn’t a flashy feature. It won’t generate “Java is reinvented” thumbnails. But it fixes something that has felt slightly off for years. In Java 26 we have the fourth preview of this feature, and it something that worth talking about.

Let’s take a look at what changed — and why it actually matters.

The Awkward Gap in Pattern Matching

Before Java 23, pattern matching was strictly tied to reference types.

Object value = 10;

if (value instanceof Integer i) {
    System.out.println(i + 1);
}

This works. But it comes with baggage:

You’re dealing with Integer, not int
There’s implicit unboxing
The intent is slightly obscured

It gets worse when you realize that Java already has a rich set of primitive types — but pattern matching simply ignored them.

So even in modern Java, you’d still end up writing code that feels… older than it should.

Pattern Matching for Primitive Types

Java 23 changes that by allowing primitive patterns directly in instanceof.

Before

Object value = 10;

if (value instanceof Integer i) {
    int v = i.intValue();
    System.out.println(v + 1);
}

Now

Object value = 10;

if (value instanceof int i) {
    System.out.println(i + 1);
}

No wrapper. No manual unboxing. No extra noise.

Just the value, in the form you actually want.

What’s happening here is simple:

The runtime checks whether the value can be represented as an int
If it can, it binds it directly to a primitive variable
If it can’t, the condition fails

That’s it.

Where This Gets Interesting

On its own, this looks like a small improvement. But it becomes much more interesting when combined with other features.

Matching Different Numeric Types

Object value = 10L;

if (value instanceof int i) {
    System.out.println("int: " + i);
} else if (value instanceof long l) {
    System.out.println("long: " + l);
}

This gives you a clean way to refine types without bouncing through wrapper classes.

You’re no longer matching objects that represent numbers. You’re matching the numbers themselves.

Pattern Matching in switch

This is where things start to feel really consistent.

static String describe(Object value) {
    return switch (value) {
        case int i -> "int: " + i;
        case long l -> "long: " + l;
        case double d -> "double: " + d;
        default -> "unknown";
    };
}

Before Java 23, this kind of code simply wasn’t possible with primitives.

Now it is — and it fits naturally with everything else pattern matching already does.

Conversions (With Some Rules)

There’s also an important detail: not every numeric conversion will match.

Object value = 10;

if (value instanceof long l) {
    System.out.println(l); // works (int → long)
}

But:

Object value = 10.5;

if (value instanceof int i) {
    // does not match
}

The general idea is:

Safe (widening) conversions may match
Lossy (narrowing) conversions won’t

This keeps behavior predictable and avoids subtle bugs.

Why This Actually Matters

This feature is easy to underestimate. It doesn’t introduce a new paradigm. It doesn’t change how you structure systems.

But it removes friction in places where Java still felt unnecessarily verbose.

Less Boxing, Less Noise

Before:

if (obj instanceof Integer i) {
    int v = i;
}

Now:

if (obj instanceof int v) {
    ...
}

It’s a small change — but it aligns the code with what you actually care about.

More Consistent Pattern Matching

Java has been moving toward a unified pattern matching model:

instanceof patterns
switch patterns
record patterns
deconstruction patterns

Primitive patterns were the missing piece.

Now the model feels complete.

Better Fit for Real-World Code

This becomes especially useful in:

Generic APIs dealing with Object
Data processing pipelines
Serialization/deserialization layers
Switch-based dispatch logic

Anywhere values flow in a loosely typed way, this helps you regain type clarity without ceremony.

A Few Things to Keep in Mind

Even though this is straightforward, there are still a couple of rules worth remembering.

Not Every Conversion Works

Be careful with narrowing conversions:

double → int
long → int

If precision would be lost, the pattern simply won’t match.

Don’t Get Clever for the Sake of It

You can write:

if (value instanceof int i && i > 10 && i % 2 == 0) { ... }

But like most modern Java features, the goal is clarity — not cleverness.

Final Thoughts: A Small Feature That Fixes a Big Gap

Pattern matching has been one of the most important evolutions in modern Java. But until now, it had a blind spot: primitives.

Java 23 fixes that, and Java 26 bring it closer to a stable feature.

No revolution. No paradigm shift. Just a missing piece finally added.

And honestly, that’s very on-brand for Java. It doesn’t rush features out the door. It lets them mature, integrates them carefully, and eventually makes them feel like they’ve always been there. This is one of those cases.

If you’re already using pattern matching heavily, this will feel like a natural extension. If you’re not, this might be the nudge that makes it click. Either way, it’s another step toward making Java code a little cleaner — and a little more honest about what it’s actually doing.

What do you think? Is this something you see yourself using, or just another nice-to-have?

Originally posted on my blog, Memory Leak

Java 25 After the Hype: 5 Features That Actually Matter

Felipe Stanzani — Wed, 04 Mar 2026 18:00:11 +0000

When a new Java version drops, the internet goes through its usual cycle: launch posts, conference talks, YouTube thumbnails screaming “GAME CHANGER,” and LinkedIn hot takes about how everything has changed forever.

Then reality settles in.

A few months after the release of Java 25, most teams aren’t rewriting their systems. They’re shipping features, fixing bugs, and trying to keep production stable. That’s when we can finally answer a more interesting question:

Which Java 25 features are still being discussed and actually used?

This isn’t a launch recap. This is a “post-hype” filter. Here are five Java 25 features that have proven they’re more than marketing bullets.

1. Structured Concurrency: Concurrency That Reads Like Logic (preview)

For years, Java concurrency meant juggling ExecutorService, Future, timeouts, and cancellation semantics that were easy to get wrong.

Structured Concurrency changes the mental model. Instead of spawning detached tasks and hoping everything is cleaned up properly, you treat concurrent tasks as a single logical unit.

Before

ExecutorService executor = Executors.newFixedThreadPool(2);

Future<User> userFuture = executor.submit(() -> fetchUser());
Future<Orders> ordersFuture = executor.submit(() -> fetchOrders());

User user = userFuture.get();
Orders orders = ordersFuture.get();

You’re responsible for:

Cancellation
Error propagation
Proper shutdown
Timeouts

With Structured Concurrency

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var user = scope.fork(this::fetchUser);
    var orders = scope.fork(this::fetchOrders);

    scope.join();
    scope.throwIfFailed();

    return new UserProfile(user.get(), orders.get());
}

Now:

If one task fails, the others are cancelled.
The lifecycle is explicit.
The code reflects intent.

Why it’s still relevant months later:

Because teams building high-throughput APIs, especially with virtual threads, are adopting it. It reduces subtle production bugs. This isn’t syntactic sugar — it’s operational sanity.

2. Scoped Values: A Safer Alternative to ThreadLocal

ThreadLocal has been both useful and dangerous. It works — until you mix it with thread pools or forget to clean it up.

Scoped Values offer a safer, more explicit model. They are immutable and bound to a dynamic scope.

Old Way (ThreadLocal)

private static final ThreadLocal<String> currentUser = new ThreadLocal<>();

currentUser.set("felipe");
processRequest();
currentUser.remove();

Easy to forget cleanup. Hard to reason about with thread reuse.

With Scoped Values

static final ScopedValue<String> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, "felipe")
           .run(() -> processRequest());

Immutable.
Automatically scoped.
No manual cleanup.
Designed to work cleanly with virtual threads.

Why it’s still in discussion:

Framework authors and library maintainers are actively evaluating it as a replacement for ThreadLocal in request-scoped data. That alone makes it strategically important.

3. Generational Shenandoah GC: Practical Performance Gains

Garbage Collection improvements don’t trend on X for long. But in production environments, they matter more than most language features.

Generational Shenandoah combines:

Low pause times
Generational hypothesis (most objects die young)
Large heap friendliness

For services with:

High allocation rates
Large heaps
Strict latency requirements

…it’s a serious option.

Why this one survived the hype cycle:

Because ops teams and performance engineers care. Lower pause times and better memory behavior translate directly into cost savings and more predictable latency.

It’s not flashy — it’s practical.

4. Compact Object Headers: Memory Efficiency at Scale

Compact Object Headers reduce the memory footprint of Java objects by shrinking object metadata.

On small apps? You won’t notice.

On:

High-density containerized environments
Large in-memory caches
Massive object graphs

You might.

The benefit compounds when running:

Microservices fleets
Kubernetes clusters
Cloud-native workloads with tight memory limits

Why it still matters:

Because memory is money. And when you multiply small per-object savings by millions of objects, the math becomes real.

5. Pattern Matching Maturity: Primitive types on pattern matching (preview)

Pattern matching has been evolving over the last releases, and Java 25 continues refining it, supporting primitive types (preview)

if (object instanceof int myInt) {
    System.out.println("This is an int number:" + myInt);
}

No more casting noise. More expressive intent.

Why it survived the hype:

Because it reduces friction in everyday code. This is the kind of incremental improvement that doesn’t make headlines but quietly improves developer experience.

Final Thoughts: Stability Is the Real Feature

What truly defines its relevance months later isn’t that label — it’s which features teams actually keep using.

The survivors tend to have three traits:

They improve correctness (Structured Concurrency).
They improve safety (Scoped Values).
They improve performance (GC + memory changes).
They reduce boilerplate without being gimmicky (Pattern Matching).

No revolutions. No paradigm shifts. Just steady refinement.

And honestly? That’s why many of us are still here after decades.

Java doesn’t chase trends. It absorbs what works, hardens it, and makes it boring in the best possible way.

If you’ve already migrated to Java 25, what are you actually using in production? And if you haven’t upgraded yet, what’s holding you back?

Let’s discuss.

Originally posted on my blog, Memory Leak

Spring Boot 4: Brief Upgrade Guide and Code Comparison

Felipe Stanzani — Fri, 16 Jan 2026 20:33:49 +0000

If you’ve been following my blog, you know I love a good migration story. Whether it’s moving to TanStack Start or refining shadcn/ui forms, the goal is always the same: better developer experience and more robust code.

Today, we’re looking at the big one. Spring Boot 4.0 is officially out, and it’s arguably the most important release since 3.0. It moves the baseline to &Java 17 (with a massive push for Java 25), adopts Jakarta EE 11, and introduces features that finally kill off years of boilerplate.

Let’s look at exactly what changed and how your code will look before and after the upgrade.

1. Native API Versioning

For years, versioning an API in Spring meant custom URL paths, header filters, or complex RequestCondition hacks. Spring Boot 4 brings this into the core framework.

The Spring Boot 3 Way (Manual Pathing)

// You had to manually manage the path segments
@RestController
@RequestMapping("/api/v1/orders")
public class OrderControllerV1 { ... }

@RestController
@RequestMapping("/api/v2/orders")
public class OrderControllerV2 { ... }

The Spring Boot 4 Way (Native Mapping)

Now, versioning is a first-class citizen. You can keep the path clean and let Spring handle the routing logic via headers, query params, or path segments.

@RestController
@RequestMapping(path = "/orders")
public class OrderController {

    @GetMapping(version = "1")
    public List<OrderV1> getOrdersV1() { ... }

    @GetMapping(version = "2")
    public List<OrderV2> getOrdersV2() { ... }

}

Pro Tip: Configure the strategy in your application.properties:

spring.mvc.apiversion.use.header=X-API-Version
spring.mvc.apiversion.default=1

2. Declarative Resilience (No More Spring Retry)

In the Spring Boot 3 era, you usually had to pull in the spring-retry dependency and use @EnableRetry. In Spring Boot 4, basic resilience patterns like Retry and Concurrency Limits are built directly into spring-context.

Spring Boot 3 (Requires External Dependency)

// Requires @EnableRetry in your config
@Service
public class StockService {
    @Retryable(value = {NetworkException.class}, maxAttempts = 2)
    public void updateStock() { ... }
}

Spring Boot 4 (Native & Robust)

The new native @Retryable and @ConcurrencyLimit (Bulkhead pattern) work out of the box with the new spring-boot-starter-resilience.

@Service
public class StockService {

    @Retryable(includes = NetworkException.class, maxRetries = 3)
    @ConcurrencyLimit(limit = 5) // Native Bulkhead pattern!
    public void updateStock() {
        // Automatically retries and limits concurrent threads
    }
}

3. Testing with RestTestClient

Spring Framework 7 introduces RestTestClient, which effectively replaces the choice between MockMvc and WebTestClient for most scenarios. It provides a single, fluent API that works for both mock environments and real running servers.

Spring Boot 3 (Choice of Two APIs)

// MockMvc for internal tests or WebTestClient for reactive/live
@Autowired
private MockMvc mockMvc;

mockMvc.perform(get("/hello"))
    .andExpect(status().isOk());

Spring Boot 4 (Unified Fluent API)

@Autowired
private RestTestClient client;

@Test
void testHello() {
    client.get().uri("/hello")
        .exchange()
        .expectStatus().isOk()
        .expectBody(String.class).isEqualTo("Hello World");
}

4. Architectural Modularization

Spring Boot 4 has undergone a "diet." The internal spring-boot-autoconfigure JAR has been split into dozens of smaller, technology-specific modules.

Feature	Spring Boot 3	Spring Boot 4
Auto-config	Monolithic autoconfigure.jar	Small, focused modules (e.g., spring-boot-autoconfigure-data-jpa)
AOT / Native	Basic GraalVM support	Optimized GraalVM 25 support with lower memory footprint
Startup	Slower due to classpath scanning	Faster build/boot via modular hints

If you notice missing auto-configurations after upgrading, you may need to add a specific starter for that technology (e.g., spring-boot-starter-flyway instead of just the Flyway core JAR).

5. Type Safety: The JSpecify Shift

Null safety is no longer a "suggestion." Spring Boot 4 fully adopts JSpecify. This isn't just a new set of annotations; it changes how Kotlin and static analysis tools view your code.

Spring Boot 3: Used a mix of @Nullable from various packages (JSR-305, JetBrains).
Spring Boot 4: Standardizes on org.jspecify.annotations.

Final Thoughts: The Road to Java 25

While the baseline is Java 17, the real magic of Spring Boot 4 happens on Java 25. With virtual threads enabled (spring.threads.virtual.enabled=true), the framework optimizes internal task executors to use lightweight threads, making your blocking code perform like reactive code without the complexity.

Ready to migrate?

Move to Spring Boot 3.5 first - if you are not already there.
Fix all deprecation warnings (especially around RestTemplate and old Actuator properties).
Flip the switch to Spring Boot 4.0 and enjoy a leaner, safer backend.

What’s your favorite new feature? I’m personally voting for native API versioning—it's about five years overdue! Let me know in the comments.

Originally posted on my blog - Memory Leak

JSON is Making You Lose Money!!!

Felipe Stanzani — Sun, 02 Nov 2025 14:20:05 +0000

Let's be real: every time you shove a bloated JSON blob into an LLM prompt, you're literally burning cash. Those curly braces, endless quotes, and repeated keys? They're token vampires sucking your OpenAI/Anthropic/Cursor bill dry. I've been there – cramming user data, analytics, or repo stats into prompts, only to hit context limits or watch costs skyrocket.

But what if I told you there's a format that cuts tokens by up to 60%, boosts LLM accuracy, and was cleverly designed for exactly this problem? Meet TOON (Token-Oriented Object Notation), the brainchild of Johann Schopplich – a dev who's all about making AI engineering smarter and cheaper.

Johann nailed it with TOON over at his original TypeScript repo: github.com/johannschopplich/toon. It's not just another serialization format; it's a lifeline for anyone building AI apps at scale.

Why JSON is Robbing You Blind in LLM Prompts

JSON is great for APIs and config files. But for LLM context? It's a disaster:

Verbose AF: Braces {}, brackets [], quotes around every key and string – all eating tokens.
Repeated Keys: In arrays of objects, every row repeats the same field names. 100 users? That's 100x "id", "name", etc.
No Built-in Smarts: LLMs have to parse all that noise, leading to higher error rates on retrieval tasks.
Token Explosion at Scale: A modest dataset can balloon to thousands of unnecessary tokens.

Result? Higher costs, slower responses, and more "context too long" errors. If you're querying GPT-5-nano or Claude with tabular data, JSON is quietly making you poor.

Enter TOON: The Token-Slaying Hero

TOON flips the script by blending YAML's clean indentation with CSV's tabular efficiency – but optimized for LLMs. Key differences from JSON:

Tabular Arrays: Declare fields once in a header, then stream rows comma/tab/pipe-separated. No repeating keys!
Minimal Punctuation: Ditches braces/brackets/quotes where possible. Indentation handles nesting.
Explicit Lengths: [N] prefixes arrays so LLMs know exactly what's coming – reduces parsing errors.
Smart Quoting: Only quotes when needed (e.g., strings with delimiters or specials).
Delimiter Options: Comma (default), tab, or pipe for extra token wins (tabs often tokenize best).

TOON shines on uniform arrays of objects – think user lists, analytics rows, or GitHub repos. For non-uniform or deeply nested data, it gracefully falls back to list format (still slimmer than JSON).

Real Examples: JSON vs TOON

Classic JSON Bloat (257 tokens for a tiny e-commerce order):

{
    "items": [
        { "sku": "A1", "qty": 2, "price": 9.99 },
        { "sku": "B2", "qty": 1, "price": 14.5 }
    ]
}

TOON Magic (166 tokens – 35% savings):

items[2]{sku,qty,price}:
  A1,2,9.99
  B2,1,14.5

Nested? No problem:

orders[1]:
  - users[2]{id,name}:
      1,Ada
      2,Bob
    status: active

Primitive arrays inline:

tags[3]: admin,ops,dev

And for wonky data, it uses clean lists:

mixed[3]:
  - 42
  - name: Ada
  - "quoted, string"

Benchmarks That'll Make You Switch Today

Johann's rigorous tests (using GPT-5 tokenizer) across real datasets prove TOON crushes JSON:

GitHub Repos (top 100): 8,745 tokens vs JSON's 15,145 (42% saved)
Daily Analytics (180 days): 4,507 vs 10,977 (59% saved)
E-Commerce Orders: 166 vs 257 (35% saved)
Total: 13,418 vs 26,379 (49% average savings)

Accuracy? TOON hits 70%+ on retrieval tasks across GPT-5, Claude, Gemini, and Grok – often beating JSON while using half the tokens. Check the full spec for details: TOON Spec.

Pro tip: Use tab delimiters for even more savings on big tables!

Hands-On: TOON in TypeScript (The OG)

Install the original:

npm install @toon-format/toon

Encode:

import { encode } from "@toon-format/toon";

const data = {
    users: [
        { id: 1, name: "Alice", role: "admin" },
        { id: 2, name: "Bob", role: "user" },
    ],
};

console.log(encode(data, { delimiter: "\t" })); // Tab for extra savings!

Output:

users[2 ]{id    name    role}:
  1 Alice   admin
  2 Bob user

Decode back to JS objects too. CLI for quick conversions: npx @toon-format/cli data.json --stats.

TOON in Java: Meet JToon (My port)

Java devs rejoice! JToon brings TOON to the JVM – Maven Central ready.

Add it:

<dependency>
    <groupId>com.felipestanzani</groupId>
    <artifactId>jtoon</artifactId>
    <version>0.1.1</version>
</dependency>

Code:

import com.felipestanzani.jtoon.JToon;
import com.felipestanzani.jtoon.Delimiter;
import com.felipestanzani.jtoon.EncodeOptions;

record Item(String sku, int qty, double price) {}
record Data(List<Item> items) {}

var items = List.of(new Item("A1", 2, 9.99), new Item("B2", 1, 14.5));
var data = new Data(items);

var options = new EncodeOptions(2, Delimiter.TAB, true);  // Tabs + length markers
System.out.println(JToon.encode(data, options));

Output:

items[#2 ]{sku qty price}:
  A1 2 9.99
  B2 1 14.5

Even encodes JSON strings directly: JToon.encodeJson(jsonString).

TOON Everywhere: Ports Galore

TOON's spec is open and crystal-clear, so ports are popping up:

TypeScript/JS (original): github.com/johannschopplich/toon
Java (JToon – battle-tested): github.com/felipestanzani/JToon
.NET: ToonSharp
Crystal: toon-crystal
Dart: toon
Elixir: toon_ex
Gleam: toon_codec
Go: gotoon
OCaml: ocaml-toon
PHP: toon-php
Python: python-toon or pytoon
Ruby: toon-ruby
Rust: rtoon
Swift: TOONEncoder

Pick your poison and start saving.

Stop Losing Money – Switch to TOON Now

JSON had its time. For LLM prompts, TOON is the future: cheaper, faster, more accurate. Thank Johann Schopplich for this gem – follow him at byjohann.link for more AI wizardry.

Try it in your next prompt. Your wallet (and your LLMs) will thank you. What's your biggest token horror story? Drop it in the comments – and share this if you're tired of JSON waste!

Originally posted on my blog, Memory Leak

Demystifying Object-Oriented Programming: Pt. 2

Felipe Stanzani — Thu, 09 Oct 2025 12:04:29 +0000

Welcome back! At the end of our last post, we hit a bit of a roadblock. We had successfully organized our F1, PickupTruck, and SUV classes to inherit from a base Car class. But then, we were faced with a new challenge:

A bicycle, a speedboat, and an electric car. They are all vehicles, but trying to force them into a single Vehicle inheritance hierarchy would be a nightmare. A speedboat doesn't have wheels, and a bicycle doesn't have an engine in the traditional sense. A simple extends Vehicle starts to feel clunky and wrong. How do we model things that share behaviors but are fundamentally different things?

The answer lies in moving beyond the idea that everything must share a common ancestor and instead thinking about what they can DO.

Interfaces: A Contract of Behavior

Let’s ask a different question. Instead of asking what these objects are, let's ask what they have in common from a user's perspective. A person can:

Steer them
Make them go forward
Slow them down

In Object-Oriented Programming, when we want to guarantee that different classes share a common set of behaviors, we use an INTERFACE. Think of an interface not as a blueprint for an object, but as a contract. It’s a list of methods that a class promises to implement. It defines WHAT a class can do, but not HOW it does it.

Let's create a contract for anything that can be driven. We'll call it Drivable.

// Interface
public interface Drivable {
  void turnLeft(double degrees);
  void turnRight(double degrees);
  void accelerate();
  void brake();
}

Notice a few things. We use the interface keyword, not class. And the methods have no body—no {} with code inside. The Drivable interface simply states: "Any class that wants to be considered Drivable MUST provide its own implementation for these four methods."

Now, our classes can sign this contract using the implements keyword.

public class Car implements Drivable {
  // ... all the car attributes

  @Override
  public void accelerate() {
    // Code to make the engine burn fuel and turn the wheels
  }

  // ... other Drivable methods implemented
}

public class Bicycle implements Drivable {
  // ... bicycle attributes like pedals, handlebars

  @Override
  public void accelerate() {
    // Code that represents the rider pedaling faster
  }

  // ... other Drivable methods implemented
}

public class Speedboat implements Drivable {
  // ... speedboat attributes like hull, propeller

  @Override
  public void accelerate() {
    // Code to engage the propeller and push water
  }

  // ... other Drivable methods implemented
}

With interfaces, we've solved our problem! We haven’t forced a bicycle to have an engine, or a car to have a propeller. We simply grouped them by a common capability: being drivable. A class can also implement multiple interfaces. A modern smart car could be Drivable, ConnectableToInternet, and HasGPS, for example.

Polymorphism: One Action, Many Forms

This leads us to one of the most powerful concepts in OOP: POLYMORPHISM. The word literally means "many forms." It’s the ability to treat objects of different classes as if they were the same type, as long as they adhere to the same contract (interface).

Imagine you have a garage. You can put all your drivable things in it.

Drivable mySuv = new SUV();
Drivable myBike = new Bicycle();
Drivable myBoat = new Speedboat();

List<Drivable> garage = new ArrayList<>();
garage.add(mySuv);
garage.add(myBike);
garage.add(myBoat);

Now for the magic. We can loop through our garage and tell everything to accelerate, and each object will know how to perform that action in its own unique way.

for (Drivable vehicle : garage) {
  vehicle.accelerate(); // The SUV roars, the bike pedals, the boat throttles up!
}

This is polymorphism in action. The same method call, vehicle.accelerate(), produces entirely different results depending on the actual object. You, the programmer, don’t need to know or care what type of object it is at that moment. You only need to know that it’s Drivable and can therefore accelerate. This makes your code incredibly flexible and easy to extend.

Abstract Classes: The Best of Both Worlds?

So, are interfaces the solution to everything? Not quite. Sometimes, you have a group of classes that are very closely related—they really do share a common identity and implementation, not just a behavior.

Let's go back to our Car example. We have gasoline cars, electric cars, and hybrid cars. They are all fundamentally cars. They all share a chassis, wheels, and a steering mechanism that works the same way. It would be wasteful to re-write the turnLeft method for every single type of car.

This is where an ABSTRACT CLASS comes in. An abstract class is a hybrid between a regular class and an interface.

Like a class, it can have attributes and fully implemented methods.
Like an interface, it can have abstract methods that have no implementation.
You cannot create an instance of an abstract class directly (you can't build a generic "Car," only a specific type like an ElectricCar).

public abstract class Car {
  // Attributes all cars share
  Chassis chassis;
  Wheel[] wheels;

  // A concrete method that all subclasses will inherit
  public void turnLeft(double degrees) {
  // The logic for turning is the same for all cars
  System.out.println("Turning left.");
  }

  // An abstract method that subclasses MUST implement
  public abstract void refuel();
}

Now, specific car types can extend this abstract class. They inherit the chassis, wheels, and the turnLeft method for free, but they are forced to provide their own logic for refuel.

public class GasolineCar extends Car {
  @Override
  public void refuel() {
    System.out.println("Pumping gasoline.");
  }
}

public class ElectricCar extends Car {
  @Override
  public void refuel() {
    System.out.println("Plugging into charging station.");
  }
}

Interface vs. Abstract Class: When to Use Which?

This is a classic question, but the distinction is clear once you grasp the core idea.

Use an Abstract Class for objects that are closely related in an "is-a" relationship. An ElectricCar is a Car. It allows you to share common code and attributes among a family of classes. A class can only extend one abstract class.
Use an Interface for objects that share a common capability, often in a "can-do" relationship. A Car can be Drivable. A Drone can be Flyable. A SmartSpeaker can be ConnectableToInternet. A class can implement many interfaces.

Wrapping Up

Today, we've added three more powerful concepts to our OOP toolkit:

Interface: A contract defining behaviors (what it CAN DO).
Polymorphism: Treating different objects as the same type, allowing one action to have many forms.
Abstract Class: A partial blueprint for a family of related classes, sharing common code (what IT IS).

By understanding when to use inheritance, abstract classes, and interfaces, you can build software that is flexible, reusable, and much easier to manage. You can now model complex relationships without tying yourself in knots.

What are your thoughts? Have you struggled with these concepts before? Leave your comments, suggestions, and questions below. See you in the next post!

Originally posted on my blog, Memory Leak

[Updated] Seamless Forms with shadcn/ui and TanStack Form

Felipe Stanzani — Fri, 26 Sep 2025 21:21:22 +0000

In my post, "Life after Next.js: A New and Sunny Start," I talked about my journey migrating to TanStack Start and the freedom it brought. One of the loose ends I mentioned was the form situation. I'm a big fan of the aesthetics and developer experience of shadcn/ui, but its default form component is built on react-hook-form. As I'm going all-in on the TanStack ecosystem, I naturally wanted to use TanStack Form.

This presented a classic developer dilemma: do I stick with a component that doesn't quite fit my new stack, or do I build something better? The answer was obvious. I couldn't find a clean, existing solution that married the beauty of shadcn/ui with the power and type-safety of TanStack Form. So, I decided to build it myself.

Today, I'm excited to share the result: a component that seamlessly integrates shadcn/ui with TanStack Form, preserving the core principles of both libraries. It's type-safe, easy to use, and maintains that clean shadcn/ui look and feel.

You can check out the component's website and find the full source code on the GitHub repository.

Why Bother?

TanStack Form offers incredible power with its framework-agnostic, type-safe approach to form state management. shadcn/ui, on the other hand, provides beautiful, accessible, and unopinionated components. The goal was to get the best of both worlds without any compromises. This component acts as the bridge, giving you:

Full Type-Safety: Infer types directly from your validation schemas (like Zod, Valibot, etc.).
Seamless TanStack Integration: Leverage TanStack Form’s state management and validation logic.
Consistent shadcn/ui Styling: Use the form components you already know and love.

How to Get Started

Setting it up is straightforward. Follow these steps, and you'll have type-safe, beautiful forms up and running in minutes.

1. Install shadcn/ui

If you haven't already, initialize shadcn/ui in your project.

npx shadcn-ui@latest init

2. Install TanStack Form

Next, add the TanStack Form library.

npm install @tanstack/react-form

3. Copy the Core Components

My solution consists of two key files. Download them from the GitHub repository and place them in the correct folders:

form.tsx: Copy this to your components/ui folder.
form-hook.tsx: Copy this to a hooks folder in your project's root.

4. Add shadcn/ui Components

Finally, add the shadcn/ui components you'll need for your forms.

npx shadcn-ui@latest add button input label form

How to Use It

Once installed, using the component is intuitive. The structure will feel very familiar to anyone who has used shadcn/ui's original form component.

1. Define your Form Logic

First, define your form's schema (using Zod in this example) and create the form instance with the useAppForm hook. Here you'll set default values, validators, and your onSubmit handler.

import { useAppForm } from "@/hooks/form-hook";
import { z } from "zod";

const userSchema = z.object({
    email: z.string().email("Invalid email address"),
});

export function MyFormComponent() {
    const form = useAppForm({
        defaultValues: {
            email: "",
        },
        validators: {
            onChange: userSchema,
        },
        onSubmit: async ({ value }) => {
            alert(`Hello ${value.email}!`);
        },
    });
    // ...
}

2. Build the Form Component

Now, construct your form using the components provided. The <form.AppForm> component links your form instance, and <form.AppField> connects each input to the form state.

Here’s a complete example:

import { useAppForm } from "@/hooks/form-hook";
import { z } from "zod";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import {
  Form,
  Field,
  FieldLabel,
  FieldControl,
  FieldDescription,
  FieldError,
} from "@/components/ui/form";

const userSchema = z.object({
  email: z.string().email("Invalid email address"),
});

export function EmailForm() {
  const form = useAppForm({
    defaultValues: {
      email: "",
    },
    validators: {
      onChange: userSchema,
    },
    onSubmit: async ({ value }) => {
      // Pretend to submit for 500ms
      await new Promise((resolve) => setTimeout(resolve, 500));
      alert(`Hello ${value.email}!`);
    },
  });

  return (
    <form.AppForm>
      <Form className="space-y-4">
        <form.AppField name="email">
          {(field) => (
            <Field>
              <FieldLabel>Email</FieldLabel>
              <FieldControl>
                <Input
                  type="email"
                  placeholder="Enter your email"
                  value={field.state.value}
                  onChange={(e) => field.handleChange(e.target.value)}
                  onBlur={field.handleBlur}
                />
              </FieldControl>
              <FieldDescription>
                {`We'll never share your email with anyone else.`}
              </FieldDescription>
              <FieldError />
            </Field>
          )}
        </form.AppField>

        <form.Subscribe
          selector={(state) => [state.canSubmit, state.isSubmitting]}
        >
          {([canSubmit, isSubmitting]) => (
            <Button type="submit" disabled={!canSubmit}>
              {isSubmitting ? "Submitting..." : "Submit"}
            </Button>
          )}
        </form.Subscribe>
      </Form>
    </form.AppForm>
  );
}

As you can see, <form.Subscribe> allows you to listen to the form's state, which is perfect for disabling the submit button while the form is invalid or submitting.

Final Thoughts

This component was born out of a real need in my own project, and I believe it can help others who find themselves in the same boat. It provides a clean, robust, and type-safe solution for building forms without having to choose between a great state manager and a great component library.

Give it a try in your next project! I'd love to hear your feedback. Feel free to open an issue or pull request on the GitHub repository. What are your go-to solutions for forms in React? Let me know in the comments below!

Originally posted on my blog

JavaScript in 2025: New Stable Features to Boost Your Code

Felipe Stanzani — Sat, 19 Jul 2025 13:36:52 +0000

Hey there! JavaScript became 30 years old in 2025. Despite being created for browsers’ front-end code, it gained more space than expected in the backend. ECMAScript 2025 (ES16), released in June, brought a handful of stable features that make coding smoother without forcing you to kneel before the latest framework altar. In this post, I’ll walk you through the standout additions with practical examples, and for each, I’ll show how you’d do the same thing the old-school way — pre-ES2025. Spoiler: the new features save you some headaches, but the fundamentals still hold strong. Let’s dive in, no fluff, just code!

1. Iterator Helpers: Functional Programming Without the Headache

What’s New: Iterator Helpers introduce a global Iterator object that lets you chain operations like .map() and .filter() on any iterable (arrays, sets, generators) in a memory-efficient, lazy way. It’s functional programming without the bloat of intermediate arrays.

Example with Iterator Helpers: Filtering and transforming a leaderboard of scores.

//
// Before
//
const scores = [100, 85, 90, 95, 70];
const topScores = scores
  .filter(score => score > 80)
  .map(score => `Score: ${score}%`);
console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]

//
// After ES2025
//
const scores = [100, 85, 90, 95, 70];
const topScores = Iterator.from(scores)
  .filter(score => score > 80)
  .map(score => `Score: ${score}%`)
  .toArray();
console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]

Why the New Way Wins: The Iterator approach is lazy, processing elements one at a time without creating temporary arrays, which is a lifesaver for large datasets. The old-school array method is simpler to read but can be less performant when chaining multiple operations. That said, for small arrays, the difference is negligible—don’t overcomplicate things just because you can.

Pro Tip: Stick to arrays for quick tasks, but use Iterator when performance matters or when working with non-array iterables like generators.

2. New Set Methods: Set Theory, Meet JavaScript

What’s New: ES2025 adds methods like intersection, union, and difference to Set, making it easier to perform set operations without clunky workarounds.

Example with New Set Methods: Finding shared songs between two playlists.

//
// Before
//
const playlistA = new Set(['Bohemian Rhapsody', 'Imagine', 'Smells Like Teen Spirit']);
const playlistB = new Set(['Imagine', 'Hotel California', 'Bohemian Rhapsody']);
const sharedSongs = new Set([...playlistA].filter(song => playlistB.has(song)));
console.log([...sharedSongs]); // ['Bohemian Rhapsody', 'Imagine']

//
// After ES2025
//
const playlistA = new Set(['Bohemian Rhapsody', 'Imagine', 'Smells Like Teen Spirit']);
const playlistB = new Set(['Imagine', 'Hotel California', 'Bohemian Rhapsody']);
const sharedSongs = playlistA.intersection(playlistB);
console.log([...sharedSongs]); // ['Bohemian Rhapsody', 'Imagine']

Why the New Way Wins: The intersection method is more readable and expressive, directly conveying intent. The old-school approach requires converting the set to an array and back, which is less elegant and slightly less performant for large sets. Still, the old way works fine for simple cases—don’t rewrite your code just to use the new shiny.

Watch Out: Sets are for unique values. If you need ordered lists or complex data, arrays or objects are still your friends.

3. JSON Modules: Importing JSON Without the Fuss

What’s New: ES2025’s JSON Modules let you import JSON files as modules with a simple import statement, using { type: 'json' }. No more fetch or require hacks.

Example with JSON Modules: Importing a config file for a dashboard.

//
// Before
//

// Browser example with fetch
async function loadConfig() {
  const response = await fetch('./config.json');
  const config = await response.json();
  console.log(config.theme); // 'dark'
  console.log(config.charts); // ['bar', 'line']
}
loadConfig();

// Node.js example with require
const config = require('./config.json');
console.log(config.theme); // 'dark'
console.log(config.charts); // ['bar', 'line']

////////////////////////////////
//
// After ES2025
//

// config.json
{
  "theme": "dark",
  "charts": ["bar", "line"]
}

// app.js
import config from './config.json' with { type: 'json' };

console.log(config.theme); // 'dark'
console.log(config.charts); // ['bar', 'line']

Why the New Way Wins: JSON Modules are cleaner and synchronous (no async boilerplate), making them ideal for static configs. The fetch approach requires async/await, which can complicate simple use cases, and require is Node-specific, breaking in browsers without a bundler. That said, fetch is still necessary for dynamic or remote JSON.

Caveat: Browser support is at 87% (mid-2025). For older environments, stick with fetch or use a bundler like Vite for polyfills.

4. Promise.try: Simplifying Promise Wrappers

What’s New: Promise.try wraps any function (sync or async) in a Promise, catching errors and returning a resolved or rejected Promise. It’s a cleaner way to unify sync and async code.

Example with Promise.try: Validating user input that might throw an error.

//
// Before
//
function validateInput(input) {
  if (!input) throw new Error('Input cannot be empty!');
  return input.toUpperCase();
}
async function runValidation(input) {
  try {
    const result = await new Promise((resolve, reject) => {
      try {
        resolve(validateInput(input));
      } catch (err) {
        reject(err);
      }
    });
    console.log(result); // 'HELLO'
  } catch (err) {
    console.log(err.message); // 'Input cannot be empty!'
  }
}
runValidation('hello');
runValidation('');

//////////////////////////////
//
// After ES2025
//
function validateInput(input) {
  if (!input) throw new Error('Input cannot be empty!');
  return input.toUpperCase();
}

const result = await Promise.try(() => validateInput('hello'));
console.log(result); // 'HELLO'
try {
  await Promise.try(() => validateInput(''));
} catch (err) {
  console.log(err.message); // 'Input cannot be empty!'
}

Why the New Way Wins: Promise.try is concise, eliminating the verbose new Promise wrapper and unifying error handling for sync and async code. The old-school approach works but is clunkier, especially when mixing sync and async logic. Still, if you’re already in an async context, a simple try-catch might suffice.

Think Twice: Don’t overuse Promise.try for straightforward async functions—async/await is often cleaner.

5. RegExp.escape: Goodbye, Manual String Escaping

What’s New: RegExp.escape escapes special regex characters in a string, making it safe for use in a RegExp constructor.

Example with RegExp.escape: Matching user input literally in a search feature.

//
// Before
//
function escapeRegExp(string) {
  return string.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

const userInput = 'hello.world*';
const escaped = escapeRegExp(userInput); // 'hello\.world\*'
const regex = new RegExp(escaped);
const text = 'hello.world* is awesome';

console.log(regex.test(text)); // true

////////////////////////////////
//
// After ES2025
//
const userInput = 'hello.world*';
const escaped = RegExp.escape(userInput); // 'hello\.world\*'
const regex = new RegExp(escaped);
const text = 'hello.world* is awesome';

console.log(regex.test(text)); // true

Why the New Way Wins: RegExp.escape is a built-in, reliable solution that saves you from writing (and debugging) your own escape function. The old-school method works but requires maintaining extra code, which can be error-prone if you miss a special character.

Heads-Up: This is niche but invaluable for dynamic regex patterns, like search or validation logic. If you rarely build regexes from user input, you might not need it.

Final Thoughts: New Tools, Same Fundamentals

ES2025’s Iterator Helpers, Set methods, JSON Modules, Promise.try, and RegExp.escape are practical additions that streamline common tasks without reinventing the wheel. Compared to the old-school approaches, they offer cleaner syntax, better performance (in some cases), and less boilerplate. But let’s not get carried away — these are tools, not magic bullets. The old ways still work, and sometimes they’re simpler for small projects or when you need broad compatibility.

As always, my advice is to experiment with these features but stay grounded in the fundamentals: write code that solves problems, not code that chases trends. Don’t let the hype on X or at tech conferences trick you into thinking you need to rewrite everything to “stay modern.” JavaScript’s beauty is in its flexibility — and the problems too.

Got thoughts on ES2025? Tried these features or stuck with the classics? Drop a comment below, and let’s geek out over what JavaScript’s doing in 2025!

Originally posted in my blog

Demystifying Object-Oriented Programming: Pt. 1

Felipe Stanzani — Mon, 07 Jul 2025 23:18:35 +0000

The Misconception of Object-Oriented Programming

When we think about object-oriented programming, we often relate it to real-world objects. The problem is this: associating object-oriented programming with tangible real-world things doesn’t work in 80% of cases, and this brings more difficulties than clarity for beginners.

Back in 1996, when I started programming in Delphi 4, its biggest competitor was Visual Basic, but Delphi was OBJECT-ORIENTED. If I had stopped at that programming course, I still wouldn't have known what this famous object-oriented programming was, and neither would the course instructor.

I worked at various companies and on commercial software projects in Delphi that were far from truly using object-oriented programming. Most Delphi programmers I met thought object-oriented programming was about dragging a button onto a screen, double-clicking it, and creating a function for that button, for example.

So, let’s talk about what object-oriented programming REALLY is.

First, look at the image below and tell me what you see.

Obviously, you see three cars: a pickup truck, an F1 car, and an SUV. The important question is: if these cars are so different, how do you know they are all cars? What makes a car a car and not a table or a piano?

There’s a concept of what a car is that’s already ingrained in your mind. A car IS LIKE THIS and SERVES THIS PURPOSE. In object-oriented programming, this concept that defines what a car is called a CLASS: it’s the definition of WHAT a certain object is. The car you touch, the one you drive from point A to point B, is what we call an OBJECT. It’s the materialized concept. This materialized concept is technically called an INSTANCE. That’s why you’ll sometimes read that an object is an instance of a class. Always translate this as: the object you touch is a concept that has been materialized.

Defining a Car: Attributes and the Blueprint of a Class

So, imagine you want to build a car from scratch. You’d take the car’s blueprint, a plan, and build that car. This blueprint is the Class; it defines WHAT the car is and HOW IT WORKS.

Let’s describe WHAT a car is. A car:

Has a chassis
Has an engine
Has wheels and tires
Has a steering wheel
Has a gear shifter
Has a driver’s seat
Has an accelerator
Has a brake

Maybe I didn’t list everything that defines a car because I forgot something, but let’s agree that not every car has a body, headlights, a clutch pedal, doors, mirrors, seat belts, or air conditioning, yet it’s still a car. Can a golf cart not be classified as a car? What about an electric car? Or a car from the 1920s? We’ll come back to this later, but there’s a basic concept of what a car is, and there are specific concepts for specific cars. Our basic class with attributes looks like this:

// Class
public class Car {
    // Attributes
    Chassis chassis;
    Engine engine;
    Wheel[] wheels;
    SteeringWheel steeringWheel;
    GearShifter gearShifter;
    DriverSeat driverSeat;
    Accelerator accelerator;
    Brake brake;
}

Notice that the car’s attributes are also names of other classes. Also note that we didn’t describe what the car DOES, only what it HAS. We call what it has ATTRIBUTES, and some of these attributes can also be broken down into multiple attributes. For example, there are thousands of different types and models of engines, each with distinct attributes.

What a Car Does: Exploring Methods and Behaviors

Now, let’s talk briefly about what a car DOES. A car:

Accommodates at least one driver
Can be turned on or off
Moves forward or backward when the driver presses the accelerator
The gear shifter changes at least whether the car moves forward or backward
Changes direction to the left or right when the steering wheel is turned left or right

Just as I might have forgotten something a car DOES, there are other things I didn’t list because not every car DOES them, like sounding a warning when the horn is pressed or lighting up when the headlights are turned on. So, our class with its methods looks like this:

public class Car {
    // Attributes hidden

    /*
    * Methods
    *
    * The internal implementation is not relevant now
    */
    public void acommodateDriver(Driver driver) {}
    public void turnOn() {}
    public void turnOff() {}
    public void accelerate() {}
    public void changeGear(Gear gear) {}
    public void turnLeft(double degrees) {}
    public void turnRight(double degrees) {}
}

What the car DOES, or the car’s BEHAVIOR, is called a METHOD or FUNCTION. A method or function is CALLED or INVOKED and can CALL other METHODS.

Imagine everything that happens when we call the accelerate method: the accelerate method activates the engine, which, depending on the gear position, will turn gears that, in turn, rotate a shaft, which will turn the wheels in a certain direction, making the car move forward or backward.

Abstraction and Encapsulation: Simplifying the Complex

When stepping on the accelerator, a person doesn’t need to understand the entire vehicle’s operating mechanism, but they expect the car to move. This is called ABSTRACTION. You don’t need to know a method’s implementation, but you know the result it will produce—and when it’s not working as it should.

Now imagine that to operate a car, you had to manually handle various cables, gears, and flammable fluids. Besides making the car’s operation much more complex, it would also be much more dangerous. The driver would be far more susceptible to cuts, burns, or operational errors. Instead, we simplify the process through an accelerator. The accelerator encapsulates the engine’s operation. This is called ENCAPSULATION. Encapsulation is the use of a safe and unique way to manipulate the object. Instead of handling the engine, the driver operates the accelerator.

So far, we’ve introduced some concepts. If you don’t CLEARLY remember a particular concept, go back a few paragraphs, reread, research, ask an AI for an explanation, but seriously, understanding these concepts is very important. So let’s list them:

Class
Object or Instance
Attribute
Method or Function
Abstraction
Encapsulation

Inheritance: How F1 Cars, Pickups, and SUVs Share a Common Base

Returning to the beginning of this post, we presented three very different cars: an F1 car, a pickup truck, and an SUV. We saw that in the basic concept common to these cars, several attributes and methods weren’t listed because not all cars have those attributes. However, we know that some cars do, and you might have wondered what to do in that case. The answer has a simple name, the one most remembered when we talk about object-oriented programming: INHERITANCE.

An F1 car inherits the attributes and methods of a base car. Similarly, a pickup truck and an SUV also inherit from the base car. But let’s talk about what makes these cars unique.

F1 car, among other characteristics:

Accommodates only the driver
Has a high-performance engine
Has aerodynamic features like a spoiler and front wing
Has a removable steering wheel
Has no doors
Has no ignition key
Is lightweight
Has tires and suspension for flat asphalt

public class F1 extends Car {
    HighPerformanceEngine engine;
    Airfoil airfoil;
    FrontSpoiler frontSpoiler;
    RemovableSteeringWheel steeringWheel;
    WeightReductionKit weightReductionKit;
    SpeedSuspension[] suspension;
    HighPerformanceTires[] tires;
}

In Java, when we use the keyword extends, we’re defining that the class inherits the attributes and methods of another class. In the case of the F1 class, it inherits from the Car class.

Notice that several attributes were added, but the engine, steering wheel, and tire attributes were replaced by other classes. Thus, our F1 car will have all the attributes of a regular car, additional attributes, and different attributes.

Similarly, a pickup truck, among other characteristics:

Has a cargo bed
Has reinforced suspension and tires suitable for carrying weight and traveling on various terrains
Usually has doors
Usually accommodates the driver plus 1 to 4 passengers
Has headlights
Has a horn

  public class PickupTruck extends Car {
      CargoBed cargoBed;
      HeavyDutyEngine engine;
      HeavyDutySuspension[] suspensions;
      AllTerrainTires[] tires;
      Door[] doors;
      PassengerSeat[] passengerSeats;
      Light[] lights;
      Horn horn;
  }

SUV, among other characteristics:

Accommodates at least 3 passengers besides the driver
Has tires and suspension suitable for carrying passenger weight on mostly urban and highway routes
Has headlights
Has a horn
Has comfortable seats
Has ample interior space

public class SUV extends Car {
    UrbanEngine engine;
    UrbanSuspension[] suspensions;
    UrbanTires[] tires;
    Door[] doors;
    DriverComfortSeat driverSeat;
    PassengerComfortSeat[] passengerSeats;
    ComfortInternalLayout comfortInternalLayout;
    Light[] lights;
    Horn horn;
}

If you’re not convinced, look below at what the SUV class would look like if we had to reimplement all the attributes and properties of the Car class:

public class SUV {
    Chassis chassis;
    UrbanEngine engine;
    UrbanSuspension[] suspensions;
    UrbanTires[] tires;
    SteeringWheel steeringWheel;
    Door[] doors;
    DriverComfortSeat driverSeat;
    PassengerComfortSeat[] passengerSeats;
    ComfortInternalLayout comfortInternalLayout;
    GearShifter gearShifter;
    Accelerator accelerator;
    Brake brake;
    Light[] lights;
    Horn horn;

    public void accommodateDriver(Driver driver) {}
    public void turnOn() {}
    public void turnOff() {}
    public void accelerate() {}
    public void changeGear(Gear gear) {}
    public void turnLeft(double degrees) {}
    public void turnRight(double degrees) {}
    /*
        Possibly, more specific methods.
    */
}

Besides writing more code for the SUV class, we’d also have to duplicate that same code for the F1 and PickupTruck classes. In addition to code duplication, we’d also face increased difficulty in keeping this code cohesive, as we’d need the exact same code in at least three different classes.

The Limits of Inheritance: A Glimpse at Future Challenges

But if you’ve made it this far and are excited about using inheritance for your classes, I have some bad news for you. Take a look at the image below and tell me what you see.

Now we have a bicycle, a speedboat, and an electric car. All three are vehicles, and they all have things in common with regular cars, but they also have very distinct features. Inheritance in this case can bring excessive complexity and significant difficulty in categorizing all these objects. What can we do to solve this? That will be the topic of our next post, where we’ll continue teaching the basic concepts of object-oriented programming.

Leave your comments, suggestions, and questions below. I’ll see you in the next post.

Originally posted in my blog

A Deep Dive into JWT for Secure Web and Mobile Sessions

Felipe Stanzani — Tue, 01 Jul 2025 17:25:07 +0000

In the early days of electronic computing, there was no concern for privacy or security because computers were not accessible to just anyone, and even if someone had access to a computer, the chances of them knowing how to use it were negligible. Moreover, computers were not typically used to store data beyond a few dozen numbers; they were primarily used as calculators.

Two decades later, even with personal computing, systems built in Clipper, Delphi, or Visual Basic ran locally or accessed databases hosted on local networks using a ring topology with coaxial cables and BNC connectors, or even on the workstation itself. The term "user session" was practically confined to academic environments and had little relevance in the real world.

The real concern for data privacy and security emerged only with the popularization of the Internet, when the first applications using network communication began to appear, and the term "user session" started to gain traction among developers.

Unlike applications that ran locally on the user's workstation, web applications are executed on application servers, with the frontend running in the user's browser. To maintain the user experience, the application server saves some user session information in memory or a database and sends a session ID to the user's browser, typically via cookies. This creates two problems. The first is that if a malicious person intercepts this ID, they can hijack the user's session, a process known as session hijacking. The second issue is that servers now need to allocate memory space or maintain database records to store some user information, without knowing whether the user is still actively using the application. With a small number of users, this may not be an issue, but with thousands or millions of users, things get significantly more complicated.

To address the first problem, several mechanisms were created, such as CSRF tokens, session binding to the user's IP address, and others. For the second issue, stateless applications emerged. Client-side applications became more complex, leveraging JavaScript, and servers began storing minimal user session data. However, with the introduction of the iPhone, which popularized smartphones and native apps running on devices, it became necessary to find a way to maintain user sessions for these devices as well.

It wouldn’t be efficient to have different methods for managing sessions across different devices, and since server-side applications had become stateless, why not apply the same principle to user sessions? This is where the JSON Web Token, more commonly known as JWT, was introduced.

The Token

JWT, defined in RFC 7519, was created to meet the needs of web and mobile applications in a stateless, scalable way, supporting cross-domain environments like APIs and single sign-on systems. So, let’s break down how it works.

A JWT is composed of three Base64-encoded JSON strings, divided into three parts separated by dots: Header.Payload.Signature:

Header: Contains information about the token type (JWT, in this case), the signing algorithm, and other metadata.
Payload: The actual token data, such as user information, permissions, token expiration date and time, and any custom data the developer wishes to include.
Signature: The most critical part for token security, as it ensures the token was issued by a trusted authentication server.

Example of a Base64-encoded token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

If you decode this token, it will reveal the following—don’t believe me? Copy it and paste it into this site:

Header:

{
    "alg": "HS256",
    "typ": "JWT"
}

Payload:

{
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true,
    "iat": 1516239022
}

Each JSON object contains several keys called claims. In the payload above, for example, sub refers to the user the token was issued to. The iat claim stands for "issued at," which stores the token issuance date in Unix timestamp format as an integer. In addition to these, there are standard claims like exp and nbf, which refer to the token’s expiration date and time and the date and time from which the token becomes valid, respectively.

Beyond standard claims, you can define custom claims, but use this feature cautiously to avoid exposing sensitive data, as the token’s content is not encrypted!

Even though the token’s content is not encrypted, the signature ensures the token’s validity for both the client and the server. To bring a JWT into the real world, imagine a wristband used at concerts or events. After presenting your ticket, the security guard gives you a wristband based on your ticket type. Depending on the wristband’s color or design, you might access the VIP area, backstage, or only the general seating. The security guards authorizing your entry don’t need to check with anyone else about your access rights, as they can validate the wristband’s authenticity themselves.

How Are JWT Tokens Issued?

In simple terms, issuing a JWT token is not much different from issuing a session ID, but some details completely change the dynamics of how these tokens are used. Let’s dive in.

The client application sends a login request to the server.
If successful, the server responds with an Auth Token and a Refresh Token.

Refresh token? Yes. Applications are dynamic. A user might gain or lose access permissions, change their name, or undergo other changes. For this reason, Authentication Tokens should have a short lifespan—short enough to avoid issues if a user’s permissions change after the token is issued, but long enough to prevent the token from expiring with every request.

But what happens if the token expires? That’s where the Refresh Token comes in.

How Is the Refresh Token Used?

Unlike the Authentication Token, the Refresh Token carries minimal information beyond what’s necessary for the server to issue a new Authentication Token. Additionally, the Refresh Token has a longer lifespan.

The token refresh process can be proactive or reactive. I like to combine both approaches.

Reactive Approach:

The client application sends a request to the server with the Auth Token in the request header.
The server verifies that the Auth Token is expired and responds with a 401 error.
The client application then sends a Token Refresh request to the server with the Refresh Token in the header.
The server validates the Refresh Token and responds with a new Auth Token and, optionally, a new Refresh Token, depending on how you choose to manage the user session.
After receiving the new token, the client resends the initial request with the valid new token.

Proactive Approach:

The client application checks that the Auth Token is expired and sends a Token Refresh request to the server with the Refresh Token in the header.
The server validates the Refresh Token and responds with a new Auth Token and, optionally, a new Refresh Token, depending on how you manage the user session.
After receiving the new token, the client sends the request with the valid new token.

As mentioned earlier, to avoid issues due to clock synchronization problems between the client and server, I like to send a refresh request when the Auth Token is close to expiring. However, I also maintain the reactive approach as a fallback in case the proactive method fails for any reason.

How Is the Auth Token Used?

There’s no mystery here: for every server request requiring authorization, the client application sends the Auth Token in the request header. If the request fails, the token refresh process is initiated.

Security Recommendations

As we discussed earlier, JWT token contents are not encrypted. Additionally, these tokens are susceptible to session hijacking. So, what can you do to reduce security risks with JWT? Below are 10 recommendations to improve the security of JWT-based applications:

Use strong signing keys (e.g., HS256, RSA) and secure storage.
Validate tokens (signature, claims like exp, aud).
Set short expiration times and use refresh tokens.
Transmit over HTTPS only.
Store tokens securely (e.g., HttpOnly cookies, not localStorage).
Implement revocation (e.g., blacklists).
Limit payload data, avoiding sensitive information.
Protect against XSS/CSRF, replay, and algorithm downgrade attacks.
Use trusted libraries and follow RFC 7519.
Monitor and log token usage.

Why Use JWT?

With so many security recommendations, why should you use JWT?

The biggest advantage of JWT over traditional sessions is that it is stateless. Since it doesn’t rely on being stored on the application server, it saves server memory and is better suited for distributed applications across multiple domains, such as APIs, mobile apps, and more.

For example, consider an application using microservices. You could have a dedicated microservice for user authentication. Other services would only need to know the authentication server’s public key to validate the user’s JWT token, without needing to query the authentication server or a database.

Additionally, JWT avoids issues like CSRF, which is a concern in applications with session ID-based systems.

Some frameworks, like Spring, have native support for JWT. There are also many libraries for token creation and validation. If you prefer, you can delegate authentication and authorization responsibilities to tools and services like Keycloak (open source), Auth0, Clerk, and others.

Libraries for Working with JWT

One of the most widely used libraries for JWT is jose, which has implementations for various languages like Java, JavaScript, TypeScript, Python, and C#.

Some languages have specific libraries, such as firebase/php-jwt for PHP, ruby-jwt for Ruby, golang-jwt/jwt for Go, cpp-jwt for C++, and SwiftJWT for Swift.

The JWT.io website provides a comprehensive and detailed list of JWT libraries. Additionally, the site’s homepage offers a tool for analyzing JWT tokens, but be cautious—do not use this tool with production tokens.

Final Thoughts

The goal of this post was not to show code but to explain the fundamental concepts of JWT. If you have a traditional website or web application with the frontend and backend in the same layer, you can continue using sessions. However, if your requirements include mobile apps, a separated frontend and backend, or distributed scenarios, JWT might be the best solution for managing your users’ sessions.

If this post helped you or if you have any questions, leave them in the comments below. Until next time!

Originally posted in my blog

Life after Next.js: A New and Sunny Start

Felipe Stanzani — Fri, 20 Jun 2025 19:04:55 +0000

A few weeks ago, I posted about my decision to move away from Next.js and the reasons behind that choice. Since projects can't just halt, I couldn't dwell too long on my decision. I had to consider several requirements for my new stack, including:

Using React as the frontend library.
Support for Server-Side Rendering (SSR).
Server-side functions.
Middleware support.
Enough flexibility to integrate libraries like React-Hook-Form and Axios.
A caching mechanism independent of the REST library.

Initially, I was torn between Remix and TanStack Start. However, Remix lacks middleware support, which would necessitate significant architectural changes and a less ideal way to manage route access. Furthermore, in recent weeks, the Remix project announced a substantial shift in direction for its V3 version. While this new direction appears very promising, it would eventually mean I'd have to rewrite everything again, and that's definitely not something I want.

TanStack Start, on the other hand, is currently in beta. Yet, it meets all my project's requirements and is built on Vite, making the project far more flexible and independent. Beyond what I've already outlined, the TanStack libraries have an excellent reputation, and this point deserves a small digression:

Utah probably isn't the first place you'd pick to catch a tan, but if your name is Tanner and you have a good sense of humor, you might just call your TypeScript library stack "TanStack." This textual detour is about him: Tanner Linsley is a programmer renowned for his profound commitment to the open-source community, developer experience, and type safety. TanStack libraries are used by hundreds of thousands of developers and adopted by everyone from startups to Fortune 500 giants. This alone lends significant credibility to TanStack Start, which, at least for me, weighs heavily in my decision for a long-term project.

Getting back on track, despite its beta status, the development team is now focused on stabilizing the framework rather than building new features, so no breaking changes are expected anymore.

Still, you might argue that adopting a beta framework for my project carries a high risk, and I agree. However, there are other valid points to consider for my project's current stage. As I've already explained, including in the previous post, going with a no-framework approach would demand a massive effort. Staying with Next.js under Vercel's grip was out of the question. This left me with Remix, which I've already discarded, and TanStack Start, which was my choice. And here's the unexpected upside for me: working with a beta framework also has its advantages.

As soon as I ran into the first development hurdles, I was directed to the TanStack Discord server. There, numerous developers exchange information and answer questions about the libraries. The project's own developers actively respond to queries, report bugs, ask for new issues to be opened, etc. Even Jack Herrington is there, participating actively!

So what? Instead of dealing with a black box and poor documentation, I'm tracking improvements in real-time, witnessing some problems being resolved as I develop my own project, and gaining a deeper understanding of how the framework itself works.

Speaking of documentation, that's another thing that genuinely surprised me. Last week, the project team removed Vinxi from the project, meaning it's now solely based on Vite, which was already planned. On the same day this version was released, all the website documentation was updated, and even a dozen example projects available on the site were already updated. These guys are truly working hard and with great dedication.

If you ask me: should I transition my production project, the one paying my bills, to TanStack Start at its current stage? My recommendation is: use Angular. If you want to build almost everything from scratch, you can use this. But if you have a project that will still take a few months to be ready, and you want the opportunity to see a framework being refined in its final stages, TanStack Start will undoubtedly be an excellent choice.

In my career, I've dealt with .Net 2.0, and believe me, that was far from a mature project, yet it was widely sold and adopted. The big difference is that before, I waited for Microsoft's good graces to fix the many issues – and anyone who used a MasterPage knows what I'm talking about – and now I have access to the code. If the project were to die (which I don't believe will happen), I'd have a project based on Vite and my own framework.

The transition so far has been quite smooth, and the TanStack Start website itself provides a very instructive guide for those, like me, migrating from Next.js.

Regarding internationalization, unfortunately, nothing pleases me as much as next-intl – for which I even created a VSCode extension. To replace it, I ended up adopting i18next, which comes closest, but it still lacks a canonical configuration solution or specific documentation for TanStack Start. So, Discord users have provided temporary solutions for now.

Another point that greatly interests me now is replacing react-hook-form with TanStack Forms, which is quite similar. I've been using shadcn/ui's form component for a while, which is based on react-hook-form. I hope a new implementation based on TanStack Forms emerges and has a good level of compatibility with the current implementation. If I have enough time, I might implement this solution and make it available on GitHub.

It's important to emphasize that despite being developed by the same team that builds the entire suite of TanStack libraries, one of TanStack Start's principles is that you are not obliged to use any of them. It's an independent framework. Do you want to use react-hook-form? Use it. Don't want to use TanStack Query? It's not even a dependency. Want to host on Vercel? Go for it. Want to put it on a Raspberry Pi hidden behind your wardrobe? Go right ahead! You are FREE.

More than just sharing my experience, I invite you to explore the project, participate, build your own projects based on TanStack Start, and contribute however you can.

If you're also moving away from Next.js or starting a new project, what are your thoughts on TanStack Start? If you've chosen another stack, share your solution in the comments! Best regards to all!

Originally posted in my blog, Memory Leak

Post inception

Felipe Stanzani — Fri, 13 Jun 2025 19:12:59 +0000

A friend of mine, Rogério Lino, presented WordPress to me in 2005. It was an amazing blog tool: simple, fast, and very easily customizable.

20 years later, and a dozen abandoned blogs that I've forgotten, I have created my website and professional blog. When I encountered WordPress again and tried to use it for my new blog, I found a bloated tool with excessive options, unnecessary plugins, managers, etc.

I tried to customize it as I wished, with a layout resembling old green-screen CRT monitors. I gave up quickly and decided to look for an alternative.

A few days later, I discovered 11ty (Eleventy). It is a static site generator that uses JavaScript, a template language of your choice for layout, and Markdown for post writing.

In my post about the need for an HTML replacement, I wrote that XML is dying because of plenty of better options. In the same way, Markdown is by far better than HTML for writing text. It requires less code to achieve the same result. Unfortunately, I can't get rid of HTML completely yet, but for my posts, I am now free of it.

I have created an awesome workflow for my posts (at least for me):

I write my posts in Notion, where I can keep them, make changes, add links, leave, come back, change them again until I decide I’m done. Afterwards, I ask an LLM to review my poor English grammar—it used to be better when I was a teenager. No shame in that; it would be worse to post incorrect texts. When I finish adjusting the text, I ask an LLM to create an image to illustrate the post, and it's ready to go.

Now, this is where things get really interesting. I copy the text from Notion into a Markdown file in my project along with its image. Then, I commit and push the project to the release branch on GitHub, where an Action is automatically executed. This action builds the HTML project and synchronizes the files with my hosting via FTP.

11ty also generates the sitemap, robots.txt, and RSS feed XML (🤢). I really don't use SEO tools for writing: they tend to make my posts feel unnatural. If you don't the way I write, don't read; it's my memory leakage.

For blog comments and reactions, I use a simple tool called Giscuss: this tool uses GitHub discussions to store these comments and reactions. You only need to configure the plugin to use a public repository discussion on GitHub. The readers must log in with their GitHub accounts to comment.

You may be interested in 11ty simplicity, and I really don't need to write another tutorial teaching how to use it, since they already created this guide, a 6-minute video teaching how to create a blog from scratch, and a base blog project in GitHub.

It is very straightforward, and believe me: if you want to customize it, it's easier than any current WordPress tool - yes, there are many of them, and they can be totally different depending on the theme you use.

If you are interested in 11ty, try it, create your blazing-fast static pages based blog, and share your experience in the comments below.

Originally posted in my blog