Your application may work for years without a framework upgrade.
But the libraries it uses can still have known vulnerabilities, even when nothing appears broken.

I have seen the same response to security findings in several projects.
A scanner reports a vulnerable library and a fixed version.
Someone adds that version directly to the build before checking where the library came from or who manages its version.

This is part of software supply chain security: we need to know which libraries we use, how we choose their versions, and what we actually ship.

I understand the urgency of fixing the finding.
It needs attention, and pinning the reported version looks like a quick fix.
But an override left in the build can make later upgrades harder to manage.

In this article, I use Spring Boot as an example.
After building an executable JAR, I run Grype against the project directory, which includes the built JAR.
This gives me quick feedback after a change, without building or deploying a container image.

# My `catalog-service` directory contains `build/libs/catalog-service*.jar` executable file
→ grype dir:./catalog-service
 ✔ Scanned for vulnerabilities     [3 vulnerability matches]  
   ├── by severity: 3 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   3 fixed, 0 not-fixed, 0 ignored 
SEVERITY  NAME               INSTALLED  FIXED IN  TYPE  VULNERABILITY   EPSS         RISK   
Critical  tomcat-embed-core  11.0.24    11.0.25   JAR   CVE-2026-65905  0.8% (53rd)  0.7    
Critical  tomcat-embed-core  11.0.24    11.0.25   JAR   CVE-2026-68525  0.6% (48th)  0.6    
Critical  tomcat-embed-core  11.0.24    11.0.25   JAR   CVE-2026-65182  0.6% (44th)  0.5

The report shows tomcat-embed-core at 11.0.24 and lists 11.0.25 as a fixed version.
Here, “3 fixed” means fixes are available.
It doesn’t mean the three vulnerabilities have already been fixed in the files I scanned.

The tempting next change is to add tomcat-embed-core:11.0.25 directly to the build.
But the report doesn’t tell me whether the framework or another part of the build manages that version.

Many frameworks manage a set of library versions for us.

The same is true for Spring Boot.
It manages Tomcat as part of its dependency set.
If I change only tomcat-embed-core, other Tomcat modules may remain on older versions.
The override may also keep taking priority after a later Spring Boot release updates Tomcat.
I would then need to find and remove it myself.

So before changing the build, I check who manages the library, which supported release includes the fix, and which versions the build actually selects.

Scanning the built files helps me quickly check changes.
I still scan the final container image because it can contain other packages from its base image.

💡 TIP:
grype is the vulnerability scanner tool I use here.
The same questions (in the next section) apply when a finding comes from another scanner.

How I Would Handle the Finding

1. Find the affected component.
Read the CVE and the fixed version.
Check whether the scanner found an application library or a package in the base image.
Check the libraries in the final image.
A change to the build will not fix an OS package in the base image.

2. Find who manages its version.
Look at the resolved runtime dependencies in the build tool.
Is the library managed by the framework?
Does another BOM manage it?
Did the project set an explicit version already?

3. If the framework manages it, check a newer supported minor release first.
Look at its support date and release notes.
Check the library version it manages.
If that version fixes the CVE, move to the new minor release and use a suitable patch from that line.
Test the change.
A patch in the old minor line doesn’t extend that line’s support date.

4. If the new minor is unavailable or doesn’t contain the fix, check the current minor line.
Has the framework released a patch that includes a fixed library version?
If so, upgrade to that patch.
If a new minor exists but we cannot finish that move before the security deadline, a fixed patch in the current line can also serve as the immediate fix.
Keep the minor upgrade on the work plan.

5. If no framework release has the fix, consider a temporary override.
Choose a fixed version that works with the application.
Check whether the library has related modules that should move together.
Write down the CVE, why the override exists, and when to review it.

6. Verify the result.
Check the resolved library versions and run the tests.
Build the application and scan its built files for quick feedback.
Then build the final container image and scan that image too.

Keep checking new framework minor and patch releases.
Remove temporary overrides when a supported framework release manages the fix.

For a Spring Boot project using Gradle Kotlin DSL and io.spring.dependency-management, a temporary Tomcat override can look like this:

/*
 * Temporary for CVE-2026-65905, CVE-2026-68525, and CVE-2026-65182.
 * Remove when the chosen Spring Boot release manages the fix.
 */
extra["tomcat.version"] = "11.0.25"

For a Maven project that inherits from spring-boot-starter-parent:

<properties>
  <tomcat.version>11.0.25</tomcat.version>
</properties>

These examples depend on the build setup.
The Gradle property above doesn’t work the same way with Gradle’s native platform(...).
Check the versions that the build actually selects before you build the image.

# Gradle:
./gradlew dependencyInsight \
   --dependency tomcat-embed-core \
   --configuration runtimeClasspath

./gradlew dependencies --configuration runtimeClasspath

# Maven:
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

After fixing and building the executable file (JAR in this context)

→ grype dir:./catalog-service
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored 

Why Regular Upgrades Matter

Small, regular upgrades keep our application healthy.

When we upgrade often, each change stays small.
If something breaks, we have fewer changes to check.

If we wait too long, many releases pile up.
API changes, configuration updates, and library updates all arrive at once in one large migration.
The end-of-support date can make that migration into an urgent task under high pressure.

Keeping dependencies current also requires a way to spot updates.
DoorDash added linting to its repositories to catch dependencies that need upgrades.

For my Spring Boot projects, I check framework releases regularly.
I look for a release that manages a fixed version, so I can remove a temporary override.

Example build: Spring Boot version and temporary Tomcat override.

cloud-native-spring-in-action/Chapter08/catalog-service/build.gradle.kts at 784b17d29038d97b0a796ebcace94b543aa040fa · fResult/cloud-native-spring-in-action

A scan finding tells us where to start.
Before changing a library version, we need to trace who manages it, choose a fix we can maintain, and check what we actually build and ship.

I shared a short visual summary on LinkedIn.
If you have handled a similar finding in another framework, I would like to hear how you approached it.

The Contract of Failure in Java Series

• Part 1: Rethinking Exceptions with Either in Java (You are here)
• Part 2: Pattern Matching in Java, Trade-offs, and Team Culture (Coming soon)

Before We Begin: A Note on “Functional Programming”
Whenever I mention Functional Programming (FP) throughout this series, I need to clear the air: I am talking about the FP discipline, not hardcore FP syntax.

I recently shared some thoughts on Kyle Simpson’s excellent post regarding this topic.
If you want a quick primer on why FP is about discipline rather than just syntax, you can check out my brief thoughts here:
https://www.linkedin.com/feed/update/urn:li:activity:7440410591934148608

.

⚠️️ Disclaimer ⚠️:
The insights in this article come from my experimental sandbox, the “Resilience Wallet Ledger”.
To be clear, I have not yet had the opportunity to implement this exact architecture in a real enterprise codebase.
Therefore, the anticipated benefits regarding team culture and incident communication are technically my hypotheses.

However, these hypotheses are built on real battle scars.
Recently, my team ported a decade-old VB.NET legacy system into a Java 17 Spring Boot 4.0 REST API.
We initially preserved its imperative style, deeply nested logic, and shared mutable states.
The real nightmare happened during a high-stress war room.
Manually tracing bugs through that messy imperative flow took us more than hour.

This experience proved a harsh reality to us.
Even when we upgrade to modern tools like Java 17, but sticking to the old imperative paradigm keeps our codebase just as unmaintainable as before.

Then, we decided to fight back.

Armed with characterization tests as our safety net, we confidently refactored the system to decouple the legacy orchestration from the business rules.
During this refactor, we discovered a severe architectural flaw: Polymorphic Data Design.
The legacy database used a single column to represent both a decimal monetary amount and an integer magic status code.
The absolute “WTF per minute” peak occurred when we found an SQL query executing SUM(transaction_amount_code) on this column to group duplicate records.

We immediately flagged a critical logical flaw as a known issue to our stakeholders: If the system grouped 2 or more normal records with values of 7.00 and 3.00, the database would return 10.00.
Tragically, 10 was a magic number representing a CRITICAL business status.
The system was blindly misinterpreting normal financial sums as severe system flags!

We resolved this by adopting Domain-Driven Design (DDD) and Functional Programming principles.
We eliminated shared mutable states, isolated the database side-effects, and extracted 19 unreadable magic numbers into a functional Rule Engine.

The value of this declarative approach was proven shortly after.
When external partners asked us to find a portion-specific IDs to test complex status scenarios, we simply traced the new isolated rule engine and found the exact test data in a few minutes per ID.
We successfully brought dead legacy knowledge back to life.

That significant reduction in cognitive load proved to me the value of explicit and declarative workflows.
It inspired the vision for this article series: if clean code helps this much at the service level, enforcing strict architectural contracts will make a profound difference at the system level.
I believe these lessons are highly worth sharing with our engineering community.

GitHub - fResult/resilience-wallet-ledger: Practice Real-World Project for Distributed Systems using Kotlin, Vavr, and Spring Webflux

Table of Content

• Introduction: Reality Check & The Goal
• The “WTF Per Minute” Metric & The Invisible Trapdoor
• The Railway Analogy
• ‘Either’ as a Legally Binding API Contract
• Functional Core, Imperative Shell: Where Does the Contract Live?
• Wrap-Up: The Foundation is Set

The Reality Check

Let’s face it:
Java 21 is out, and JEP 441 (Pattern Matching for switch) is one of the best features in years.
It helps us handle complex state evaluations beautifully.

But I know the reality of the enterprise world.
Many of you are stuck maintaining systems on Java 17, Java 11, or even the forbidden Java 8.

You see cool functional programming paradigms, but you cannot use them in your legacy codebase.

This article is for you.

We can’t use the latest switch expressions in older Java versions.
But Java 17 (LTS) already gave us Pattern Matching for instanceof (JEP 394).
This is more than enough to completely change how we handle errors. And if you are still stuck with Java 8, don’t close this tab yet.
I will show you how to use the Vavr library to get the exact same safety.

Vavr - Object-functional library for Java

The Goal: Flattening the Control Flow

I’m not here to sell you a magic trick that fixes all bugs.
The goal of this architectural shift is much more grounded: writing better and more predictable code.

How do we measure “better” code?
We measure it by the “WTFs per minute” metric during code reviews.

Our objective is to eliminate the hidden try-catch blocks scattered across our domain logic.
Right now, the execution flow probably jumps across dozens of lines due to unpredictable Exceptions.
We want to flatten that flow into a straight, boring, and highly predictable line.
We will transform errors from invisible trapdoors into explicit, manageable data.

The “WTF Per Minute” Metric & The Invisible Trapdoor

When we read code and say “WTF”, it usually comes from two different places.

First, it comes from real complexity.
This is truly bad code.
Imagine an if-else block nested three (or more) levels deep, filled with mutating shared states.
You are forced to mentally compute and track how variables change at every step.
Or imagine a try-catch block wrapping your core business logic so tightly that you cannot find the actual logic.
Or a callback and lambda hell, where you cannot track the execution flow at all.
This is garbage complexity, and it deserves the "WTF".

Second, it comes from a skill gap.
When a team first adopts new programming paradigms/concepts (in this case, Functional Programming (FP)), the code might look very alien.
Imperative developers will say “WTF” because they don’t know what the FP code actually does.
This is completely normal.
It is a learning phase.
But if we give up here and go back to writing messy imperative code just to deliver features quickly, we are making a huge mistake.
We are creating “Heisenbugs” that may randomly explode in production six months later.
Closing this skill gap today is how we buy peace of mind for the future.

.

And the biggest source of bad complexity in Java is the traditional Exception.

Let’s look at a standard method signature:

@NullMarked
public SuspendedWallet freezeForInvestigation(  
    String investigatorId, String walletId, String amlAlertId) { ... }

It looks simple and honest, but it is lying to you.
Deep inside that function, someone might write throw new WalletAlreadySuspendedException().
Or they might throw throw new AmlAlertAlreadyResolvedException().

This is an invisible trapdoor.
When this line executes, the normal flow is interrupted.
It skips the next lines of code and jumps to a catch block somewhere else.
Maybe that block is dozens of lines later.
It might be three layers up in the same service.
Or even, it is five layers up in a GlobalExceptionHandler (@RestControllerAdvice).
You can’t determine this from the method signature alone.
You may have to spend hours reading the internal implementation to find out.

Let’s look inside the actual implementation.

@NullMarked
public SuspendedWallet freezeForInvestigation(
    String investigatorId, String walletId, String amlAlertId) {

  // 1. Throw something if not found, for e.g.,
  //    - InvestigatorNotFoundException
  //    - WalletNotFoundException
  //    - AmlAlertNotFoundException
  final var investigator = investigatorRepository.findById(investigatorId).orElseThrow();
  final var wallet = walletRepository.findById(walletId).orElseThrow();
  final var alert = amlAlertRepository.findById(amlAlertId).orElseThrow();

  // 2. Guard Clauses (The immediate trapdoors)
  if (!investigator.hasComplianceRole()) {
    throw new UnauthorizedComplianceRoleException();
  }
  if (wallet.isSuspended()) {
    throw new WalletAlreadySuspendedException();
  }
  if (alert.isResolved()) {
    throw new AmlAlertAlreadyResolvedException();
  }

  // 3. The Illusion of Control (The massive try-catch)
  try {
    // ... [Imagine 30-40 lines of complex imperative logic here] ...
    // - Mutate local states first (e.g., alert.markAsProcessing)
    // - Call External Compliance API (Blocking, might timeout)
    // - Calculate freeze duration and update it to the `wallets` table
    // - Log success and send a notification
    return new SuspendedWallet(wallet.getId(), ...);

  } catch (HttpServerErrorException | ResourceAccessException ex) {
    // 4. The Teleportation Destination
    // The code jumped from the HTTP call down to here!
    // Local mutated states are now inconsistent. We log and re-throw a domain error
    throw new ExternalComplianceSystemException("Compliance system is down", ex);

  } catch (Exception ex) {
    // The ultimate sin: Catching generic Exception
    // We log the unknown failure and wrap it in a generic RuntimeException
    throw new RuntimeException("Unexpected error occurred while freezing wallet", ex);
  }
}

Want to see the practical spaghetti code?
Check this out:
https://gist.github.com/fResult/3262e8a5809e1ad029802c698d7d543e#file-imperative1_walletapplicationservice-java

Look at the method signature again.
It says it will return a SuspendedWallet.
But it actually does not.
It returns a SuspendedWallet, OR it crashes our execution flow with a runtime exception.
If the external API fails, the code teleports to the catch block, leaving our local variables in an inconsistent state.

This is what we call “The Lie”.
The method signature hides the true behavior of our domain logic.
These are the invisible trapdoors.
They wait quietly in the dark for someone to step on them.

Let’s look at the actual caller.

@NullMarked
@RestController
@RequestMapping("/wallets")
public class WalletController {

  @PostMapping("/{id}/suspensions")
  public ResponseEntity<SuspendedWallet> freezeWallet(
      @PathVariable("id") String walletId,
      @RequestBody FreezeWalletRequest request,
      @AuthenticationPrincipal Jwt jwt) {

    // The Happy Path: It looks incredibly clean and linear.
    final var suspendedWallet = walletApplicationService.freezeForInvestigation(
        jwt.getSubject(), walletId, request.amlAlertId());

    return ResponseEntity.ok(suspendedWallet);
  }
}

Then, look at the exception handlers:

@RestControllerAdvice
public class GlobalExceptionHandler {
  // The Teleportation Destination: In a completely different file!

  // ... leave dozens of exception handlers for brevity ...

  @ExceptionHandler(UnauthorizedComplianceRoleException.class)
  public ProblemDetail handleUnauthorized(...) { ... }

  @ExceptionHandler({WalletAlreadySuspendedException.class, AmlAlertAlreadyResolvedException.class})
  public ProblemDetail handleDomainConflict(...) { ... }

  @ExceptionHandler(ExternalComplianceSystemException.class)
  public ProblemDetail handleExternalSystemFailure(...) { ... }

  @ExceptionHandler(Exception.class)
  public ProblemDetail handleGenericException(...) { ... }

  // ... leave another dozens of exception handlers for brevity ...
}

If you are curious to see the full, messy reality of the exception handler,
Check this out:
- https://gist.github.com/fResult/3262e8a5809e1ad029802c698d7d543e#file-imperative2_walletcontroller-java
- https://gist.github.com/fResult/3262e8a5809e1ad029802c698d7d543e#file-imperative3_globalexceptionhandler-java

Notice how clean the WalletController looks.
It seems like nothing can go wrong.
But when an exception is thrown deep inside the service, the code completely skips the rest of the controller.
It teleports to a completely different file called GlobalExceptionHandler.

We call this “The Teleport”.

As a developer reading the controller, we may have no idea what exceptions might occur.
We have to globally search the codebase to find where the errors are handled.
If someone adds a new exception inside the service, our global handler might catch it as a generic Exception and return a 500 error silently.

This is what we call “The Pain”.

This breaks the linear flow of your program.

It forces developers to mentally follow the execution path across multiple files and layers.

It increases cognitive load massively.
We need a way to stop falling through these trapdoors.

The Railway Analogy

To fix the invisible trapdoor, we need a new mental model.
Instead of throwing exceptions, we use Railway-Oriented Programming (ROP).
Don’t worry about the fancy functional programming name.
Let’s imagine the execution flow as a train track.

The Main Track (Right)
This is our happy path.
When everything goes well, the train stays on the main track.
It moves forward smoothly to the next station.
In our code, we call this the “Right” side.

The Siding (Left)
Sometimes, things go wrong.
Maybe a user’s wallet has insufficient funds.
Maybe a wallet is already suspended.
These are expected business failures.
When this happens, we don’t derail and crash the train.
We don’t throw an exception to blow things up.
Instead, we gently switch the train to a safe side track.
In our code, we call this the “Left” side.
The train stops safely, and we know exactly why it stopped.

.

To see this in action, let’s look at the freezeForInvestigation flow as a railway system:

public record Wallet(
    String id, String ownerId, BigDecimal balance, Instant lastAccessed, String status) {

  public Either<DomainError, SuspendedWallet> freezeForInvestigation(
      Investigator investigator, AmlAlert alert, ComplianceResponse compliance, int freezeDays) {

    final var wallet = Wallet.toDomain(this);
    final var initialContext = new FreezeContext(investigator, wallet, alert);
    final var suspensionEndDate = Instant.now().plus(freezeDays, ChronoUnit.DAYS);

    // The railway starts here
    return authorizeInvestigator(initialContext) // Step 1
        .flatMap(this::ensureActiveWallet)       // Step 2
        .flatMap(this::ensureUnresolvedAlert)    // Step 3
        .map(applyFreezeWith(suspensionEndDate));       // Step 4
  }

  public static WalletDomain toDomain(Wallet wallet) {
    return switch (wallet.status()) {
      case "PENDING" -> new PendingWallet(
          wallet.id(), wallet.ownerId(), wallet.balance(), wallet.lastAccessed());
      case "ACTIVE" -> new ActiveWallet(
          wallet.id(), wallet.ownerId(), wallet.balance(), wallet.lastAccessed());
      case "SUSPENDED" -> new SuspendedWallet(
          wallet.id(), wallet.ownerId(), wallet.balance(), wallet.lastAccessed());
      default -> throw new InvariantViolationException(
          "Wallet status can be only PENDING, ACTIVE, or SUSPENDED!");
    };
  }
  
  private Either<DomainError, FreezeContext> authorizeInvestigator(FreezeContext ctx) {
    return ctx.investigator().hasComplianceRole()
        ? Either.right(ctx)
        : Either.left(new UnauthorizedComplianceRoleException("Investigator lacks compliance role"));
  }
  
  private Either<DomainError, FreezeContext> ensureActiveWallet(FreezeContext ctx) {
    return ctx.wallet() instanceof SuspendedWallet sw
        ? Either.left(new WalletAlreadySuspendedException("Wallet with id %s is already suspended".(sw.id())))
        : Either.right(ctx);
  }
  
  private Either<DomainError, FreezeContext> ensureUnresolvedAlert(FreezeContext ctx) {
    final var alert = ctx.alert();
    return alert.isResolved()
        ? Either.left(new AmlAlertAlreadyResolvedException("Alert with id %s is already resolved".formatted(alert.id())))
        : Either.right(ctx);
  }
  
  private Function<FreezeContext, SuspendedWallet> applyFreezeWith(Instant expirationDate) {
    return ctx -> new SuspendedWallet(
        id, balance, ctx.investigator().id(), ctx.alert().id(), expirationDate);
  }
}

This approach makes our code predictable.
We can see every possible turn the code can make.
There are no hidden trapdoors anymore.

‘Either’ as a Legally Binding API Contract

Railway-Oriented Programming sounds great in theory.
But how do we enforce this train track in Java?
We use a generic type called Either<Left, Right>, which is provided by Vavr.io.

Many developers think Either is just a fancy wrapper.
That is a cute assumption, but it’s completely false. 😏
It is a legally binding contract between the provider and the consumer.

The Provider’s Promise
The person writing the function makes a strict promise.
They promise never to throw an exception for an expected business error.
If the investigator is unauthorized, they will not blow up the application.
Instead, they will politely wrap that failure in a Left object and return it.
They guarantee a safe train ride.

The Consumer’s Obligation
The person calling the function also has an obligation.
Because the return type is Either, the Java compiler gets involved.
We cannot just grab the Right value and ignore the Left side.

The type system forces us to unpack the box.
We must explicitly declare what to do when it succeeds and what to do when it fails.

We cannot pretend the error does not exist anymore.

Let’s look at how the caller (the Controller) handles this new contract:

@NullMarked
@RestController
@RequestMapping("/wallets")
public class WalletController {

  @PostMapping("/{id}/suspensions")
  public ResponseEntity<?> freezeWallet(
      @PathVariable("id") String walletId,
      @RequestBody FreezeWalletRequest request,
      @AuthenticationPrincipal Jwt jwt) {

    // 1. Service now explicitly returns an Either. No hidden trapdoors!
    final Either<DomainError, SuspendedWallet> result = 
        walletApplicationService.freezeForInvestigation(
            jwt.getSubject(), walletId, request.amlAlertId());

    // 2. We handle both paths explicitly using .fold()
    return result.fold(
        this::toErrorResponse,     // Left track (Failure)
        ResponseEntity::ok         // Right track (Success)
    );
  }

  // 3. Pattern Matching (Java 21+) to map Domain Error to HTTP Status
  private ResponseEntity<ProblemDetail> toErrorResponse(DomainError error) {
      
    final HttpStatus status = switch (error) {
      case ResourceNotFound _ -> HttpStatus.NOT_FOUND;
      case BusinessRuleViolation _ -> HttpStatus.UNPROCESSABLE_ENTITY;
      case ConcurrencyConflict _ -> HttpStatus.CONFLICT;
      default -> HttpStatus.INTERNAL_SERVER_ERROR;
    };

    final var detail = ProblemDetail.forStatusAndDetail(status, error.getMessage());
    return ResponseEntity.status(status).body(detail);
  }
}

Notice that the Controller no longer throws any domain exceptions.
There is no GlobalExceptionHandler intercepting our business logic.
There is no teleportation across files.
We use Java 21’s pattern matching to map the specific DomainError to the correct HTTP Status.

The Shield Against Data Corruption
But what about real, unexpected system errors or domain invariant violations?
Imagine someone arbitrarily runs an INSERT orUPDATE script in the database (on development env 🙂).
They accidentally set a wallet balance to a negative number.
But our domain model strictly forbids negative numbers.
Or maybe they insert a random string into a wallet status column.
When our domain model loads this data, it violates a strict business invariant.
In this specific case, the provider does NOT return a Left.
The provider must fail fast and throw a InvariantViolationException or IllegalStateException immediately.

Why?
Because dead programs tell no lies.
If the data is corrupted, we must crash the process right there.
We don’t want corrupted data to flow further into our business logic.

Crashing immediately stops the bleeding and gives us a clear stack trace to fix the root cause.

Functional Core, Imperative Shell: Where Does the Contract Live?

Now we know how the Either contract works.
But where exactly do we use it?
If we use Either everywhere, our codebase will become a heavy, unreadable mess.
This is where the "Functional Core, Imperative Shell" architecture comes in.

The Functional Core

This is our Domain Model, just like the Wallet aggregate in our project.
It contains our most valuable business logic.
In this core, the code must be 100% pure.
There is absolutely no try-catch block allowed here.
There are no database queries, no HTTP calls, and no message broker publications.
If a business rule fails, the core simply returns an Either.Left.
For example, a withdrawal with insufficient funds returns a Left(WalletBalanceInsufficientException).
The core never throws an exception for business rules.
It just calculates the new state, generates domain events, and returns the data.

The Imperative Shell

This is the boundary of our system.
This is where our application interacts with the dirty, unpredictable outside world.
In the shell, using try-catch, I/O connis fine and necessary.

The Orchestrator (Application Service)
This is where we glue the pure core and the dirty shell together.
We use the Read-Decide-Write pattern inside our application service.
Let’s look at how we implemented this for our freeze wallet use case:

// In WalletApplicationService.java
@NullMarked
@Transactional
public Either<DomainError, SuspendedWallet> freezeForInvestigation(
    String investigatorId, String walletId, String alertId) {

  // ==========================================
  // 🐚 1. READ (Imperative Shell)
  // ==========================================
  // We allow I/O operations here.
  // System exceptions bubble up naturally if the database is down.
  final var investigator = investigatorRepository.findById(investigatorId).orElseThrow();
  final var wallet = walletRepository.findById(walletId).orElseThrow();
  final var alert = amlAlertRepository.findById(alertId).orElseThrow();
  
  // External HTTP calls are perfectly fine here.
  // We gather all dirty data first before calling our pure logic.
  final var complianceRes = complianceHttpClient.verifyAmlStatus(alert.id(), investigator.id());

  // ==========================================
  // 🎯 2. DECIDE (Functional Core)
  // ==========================================
  // We pass the clean data into our pure domain model.
  // This Railway chain is 100% pure.
  // It only returns a new object in memory.
  // It does NOT save anything to the database yet.
  final Either<DomainError, SuspendedWallet> result =
      wallet.freezeForInvestigation(investigator, alert, complianceRes);

  // ==========================================
  // 🐚 3. WRITE (Imperative Shell)
  // ==========================================
  // We perform side effects on each track of the railway, then return decision unchanged.
  // Success track: commit the freeze (persist, audit, announce).
  // Failure track: audit the rejected freeze.
  return result
      .peek(commitFreezeOrderedBy(investigatorId))
      .peekLeft(recordRejectedFreezeOf(walletId, investigatorId));
}

// ===== Side-effect helper methods =====
private Consumer<SuspendedWallet> commitFreezeOrderedBy(String investigatorId) {
  return suspendedWallet -> {
      walletRepository.save(Wallet.toEntity(suspendedWallet));
      auditLogger.logFreezeAttempt(suspendedWallet.id(), investigatorId, "SUCCESS");
      eventPublisher.publishEvent(new WalletFrozenEvent(suspendedWallet.id(), suspendedWallet.ownerId()));
  };
}

private Consumer<DomainError> recordRejectedFreezeOf(String walletId, String investigatorId) {
  return error -> auditLogger.logFreezeAttempt(walletId, investigatorId, "REJECTED: " + error.getMessage());
}

Notice how we gather all the necessary data from the database and external HTTP clients before starting the Railway chain.
This is the Read-Decide-Write pattern.
We keep the I/O in the Imperative Shell, and pass only pure data into our Functional Core chain.

For incoming traffic (Rest Controller / Functional Endpoints)
We might use a standard @RestController.
If we do, we can use @RestControllerAdvice to catch system exceptions and translate them globally.
However, in our modern setup, we use Spring Functional Endpoints (RouterFunction and Handler).

In this boundary layer, we unwrap the Either received from the core.

• If it is a Right, we map the data to an HTTP 200 OK or 201 Created
• If it is a Left, we convert the domain error into an HTTP 400 Bad Request, 409 Conflict, 422 Unprocessable Entity, etc.
• If a system error or an invariant violation occurs, it safely bubbles up and becomes an HTTP 5xx Server Error

For external integrations
We have Database Adapters and Message Publishers (like Kafka or RabbitMQ).
These adapters talk to external libraries that constantly throw unpredictable exceptions.
Sometimes, an adapter must catch a specific external exception and translate it into a Domain Error.
It must do this translation before passing the data into the pure Functional Core.

The rule is simple:
Keep the core pure with Either, and let the shell handle the dirty exceptions.

Wrap-Up: The Foundation is Set

In this first part, we dismantled the traditional way of handling errors.
We learned that throwing exceptions creates invisible trapdoors in our business logic.
We explored how to replace those trapdoors with a strict API contract using Either.
We discussed how to separate our pure Domain Model from the dirty external world using the Functional Core and Imperative Shell architecture.

However, getting a new mindset does not mean we can change our architecture overnight.
It takes time, intense communication, and continuous knowledge sharing.
We have to repeatedly speak the same ubiquitous language and shared team vocabulary.
We have to talk about Either, Left, and Right until it becomes normal.

But remember, we may not need to understand complex Functional Programming category theory. (But nice to understand)

We must constantly encourage Functional Programming discipline within our team.
Everyone must see exactly why predictable state transitions are always better than unpredictable mutable states.

In Part 2, we will get our hands dirty with real implementation details to support this cultural shift.
We will explore how to implement this pattern across different Java eras:

• Using switch expressions in Java 21/24
• Leveraging Record and instanceof in Java 17
• Building a lifeline for Java 8 using Vavr’s pattern matching

We will also discuss the critical trade-offs.
We must know exactly when to use Either and when to fail fast with a real exception.
Most importantly, we will dive deep into how this architectural shift transforms our team culture.

A strict technical contract forces better human communication.

We will explore how this approach shifts our code review discussions.
And I believe this is exactly what makes critical incident war rooms significantly less stressful.

Stay tuned for Part 2, and let’s elevate our engineering culture together!

The Contract of Failure in Java Series:

• Part 1: Rethinking Exceptions with Either in Java (You are here)
• Part 2: Pattern Matching in Java, Trade-offs, and Team Culture (Coming soon)

Thanks for reading until the final line.
If you’re confused or have any questions, don’t hesitate to leave comments.

Feel free to connect with me and stay updated on the latest insights and discussions.
👉 https://linkedin.com/in/fResult 👈

And happy coding 🫰🫰

I recently set up Testcontainers and Colima in my Spring Boot project.
I use Colima simply because it is a lightweight, open-source alternative to Docker Desktop.

I attached my .env file using the EnvFile plugin in the Run/Debug Configurations.

(I followed the official guide here: https://java.testcontainers.org/supported_docker_environment/#colima)

colima start --network-address
export TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock
export TESTCONTAINERS_HOST_OVERRIDE=$(colima ls -j | jq -r '.address')
export DOCKER_HOST="unix://${HOME}/.colima/default/docker.sock"

It looked correct.
But when I ran the test, it failed. 😤 😤 😤

The Error:

.
... Leave for brevity ...
.

2026-02-15T13:25:20.993+07:00 ERROR 20954 --- [Resilience Wallet Ledger] [    Test worker] tc.testcontainers/ryuk:0.13.0            : Could not start container  
  
com.github.dockerjava.api.exception.NotFoundException: Status 404: {"message":"No such container: ..."}  
 at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:241)
 ...

.
... Leave for brevity ...
.

It seemed like the test process completely ignored the environment variables I just attached.
This happens because IntelliJ defaults to using Gradle as the test runner.
Gradle runs in a separate process (daemon) and doesn’t always inherit the EnvFile configuration.

Solutions

Here are the 2 solutions I found.

1. The “Quick & Risky” Way: Check the box Enable experimental integrations (e.g. Gradle)
   (⚠️ Warning: Use with caution. It is experimental and may break at any time.)
2. The “Stable” Way: Change the test runner from Gradle to IntelliJ IDEA

Note:
I avoided disabling Ryuk.
Ryuk is responsible for cleaning up containers.
Disabling it is just a workaround, and it will leave “zombie” containers running on our machine, consuming memory.

Option 1: Enable Experimental Integrations

If you want to keep using Gradle as the runner, there is a specific setting for this.

In your Run/Debug Configuration (inside the EnvFile tab), look at the right side.
You will see a checkbox:

Enable experimental integrations (e.g. Gradle) — may break any time!

After checking this box, the test passed.

My thought:
It works, but the warning “may break any time” makes me nervous.
I don’t want to come back and fix this again in the future.

So, I prefer Option 2.

Option 2: Switch Test Runner to IntelliJ (Recommended)

This is a more permanent fix.
By switching to the IntelliJ Native Runner, the IDE handles the process directly.
It picks up the EnvFile plugin configuration 100% of the time.

How to do it:

1. Open Settings (or Preferences)
2. Go to Build, Execution, Deployment > Build Tools > Gradle
3. Change Run tests using from Gradle to IntelliJ IDEA

That’s it!
No more missing variables.
The tests just work.

I originally documented this solution in the README of my practice project, Resilience Wallet Ledger.
If you want to see how this configuration fits into a complete Spring Boot application, you can check the full setup here:

👉 GitHub: Resilience Wallet Ledger — Running Tests

Happy Coding! 🚀

Thanks for reading until the final line.
If you’re confused or have any questions, don’t hesitate to leave the comments.

Feel free to connect with me and stay updated on the latest insights and discussions.
👉 https://linkedin.com/in/fResult 👈

ผมดีใจที่เห็นพี่เดฟ (Dave Rawitat Pulam) ยังประกาศสอนคลาส Mathematics for Working Programmers อยู่เรื่อยๆ
เพราะคลาสนี้คือหนึ่งในจุดเปลี่ยนสำคัญในชีวิตการทำงานของผมเลย
(ต่อไปนี้ผมจะย่อชื่อคลาสเหลือแค่คำว่า “M4WP” นะครับ)

ชีวิตการทำงานของผมมี “จุดเปลี่ยน” ใหญ่ๆ อยู่สองครั้ง

ครั้งแรก คือการได้เจอพี่ชายท่านหนึ่งเมื่อหลายปีก่อน
ที่เปลี่ยนเด็ก (ที่มีอายุเยอะนิดหน่อย(?)) ที่เกลียดการเขียนโปรแกรมชนิดเข้าไส้
ให้กลายมาเป็นคนที่อยากจะเป็นโปรแกรมเมอร์ให้ได้
นั่นคือก้าวแรกที่สำคัญมาก…

ครั้งที่สอง คือการได้มาเรียนกับพี่เดฟ คลาสนี้ไม่ใช่คลาสที่สอนเขียนโค้ด
และ ไม่ใช่คณิตศาสตร์แบบที่เราท่องจำกันมา ไม่ใช่เรื่องการนั่งบวกลบคูณหาร
การถอดรูท หรือ มานั่งดิฟ/อินทิเกรต เพื่อหาคำตอบเป็นตัวเลข
แต่มันคือการพาไปเห็น “โครงสร้างของความเป็นเหตุเป็นผล” (Logical Structure) ที่ซ่อนอยู่เบื้องหลังทุกสิ่ง

ความเจ๋งคือ พี่เดฟแกใช้วิธี “เขียนกระดานดำ” (ด้วยชอล์ก!) สดๆ (แทบไม่เปิดสไลด์เลยถ้าไม่จำเป็น)
เพื่อพาเราค่อยๆ “ประกอบร่าง” องค์ความรู้ขึ้นมาทีละชิ้น
ผ่านบทสนทนาและการถกเถียงกันในห้องเรียนจนตกผลึก
(ส่วนสไลด์สวยๆ แกเตรียมไว้ให้เราเอาไปทบทวน
และเป็นลายแทงให้ไปค้นคว้าเพิ่มเติมเท่าที่ต้องการเลยฮะ ไม่ต้องห่วง)

การได้เห็น “โครงสร้าง” ที่ค่อยๆ ถูกกางออกมาให้เห็นกับตาตรงหน้านี่แหละ
ที่ทำให้ผมต้องอ้าปากค้าง ตบโต๊ะดังฉาด! และตาสว่างซ้ำแล้วซ้ำเล่า…

เห้ย… การสร้างซอฟต์แวร์ การแก้ปัญหาจริงๆ มันควรเป็นแบบนี้ดิ….
ไม่ใช่การเขียนโค้ดตามๆ กันมา หรือสักแต่ว่าเขียนให้มันรันผ่าน

…นั่นคือสิ่งที่ผมคิดหลายต่อหลายครั้งในระหว่างที่เรียนคลาสของพี่เดฟเป็นครั้งแรก

แม้ว่าในตอนนั้น ผมจะยังมืดแปดด้าน ผมมองไม่เห็นทางเลยว่า
จะหยิบจับทฤษฎีพวกนี้ไปแปลงเป็น Code ในงานจริงได้ยังไงในทันที
แต่สัญชาตญาณลึกๆ ของผมมันตะโกนบอกว่า “นี่แหละคือทางที่ถูกต้อง”

มันคือการ “บ่มเพาะเมล็ดพันธุ์ทางความคิด”
ที่ผมรู้ตัวทันทีเลยว่า ต้องใช้เวลาฟูมฟักอีกหลายปี
กว่าที่มันจะเติบโตและผลิดอกออกผล
ให้ผมกลายเป็น Programmer ที่เข้าใจแก่นแท้ของระบบจริงๆ

ไม่ใช่แค่ช่างก่ออิฐที่ฉาบปูนไปวันๆ

นิยามของ “Problem Solving”

สิ่งที่ Impact ผมที่สุด คือนิยามของคำว่า “Problem Solving” หรือ การแก้ปัญหา

เมื่อก่อน เวลาเจอ Bug หรือโจทย์ยากๆ ผมมักจะแก้ปัญหาแบบ “มวยวัด”
หรือก็คือการแก้เฉพาะหน้าไปเรื่อยๆ
“ก็แค่” ใส่ Log ดู State ทีละบรรทัด
แล้วแก้จนกว่าจะได้ผลลัพธ์ที่ (คิดว่า) ถูก
ทำแบบนี้วน Loop ไปเรื่อยๆ
“เหมือนเอาเทปกาวมาแปะรูรั่ว”

แต่พี่เดฟพาไปรู้จักนิยามที่เรียบง่ายแต่ทรงพลังที่สุด (ซึ่งแกบอกว่าได้มาจากหนังสือธุรกิจของญี่ปุ่นเล่มหนึ่ง):

“การแก้ปัญหา คือการพาตัวเองจาก Current State (A) ไปสู่ Desired State (B)”

หรือพูดง่ายๆ ก็คือ “การปิด Gap จากจุด A ไปยังจุด B” นั่นเอง

แค่นั้นเลยครับบ!

พูดถึงเรื่องนี้ ผมนึกถึงบทความของเพื่อนคนนึง (Rachata.Ptnn)
ที่ไปเคยเรียนคลาสเดียวกันมา
เขาเขียนอธิบายเรื่อง “Problem-Solving, Sub-Problem และ Algorithm”
พร้อมยกตัวอย่างเรื่องการลดน้ำหนักไว้ได้เห็นภาพและเข้าใจง่ายมาก

ถ้าใครอยากเจาะลึกว่าไอ้การแตก Problem A → B
ออกเป็น Sub-problems ย่อยๆ มันทำยังไง
(และทำไมมันถึงช่วยให้เราแก้โจทย์ที่ซับซ้อนได้)
ผมแนะนำให้ตามไปอ่านบทความของเขาต่อได้ฮะ
ของเขาดีมากจริงๆ ฮะ

👇🏻 จิ้ม link ข้างล่างเบาๆ ได้เบย👇🏻

Problem-Solving, Sub-Problem และ Algorithm

แล้วไงต่อ…? 🤨🧐

คุณรู้สึกว่าฟังดูเหมือนกำปั้นทุบดินใช่ไหมนะ?
แต่ในโลกของ Software Engineering … นี่คือแก่นของทุกอย่าง

มันเปลี่ยนวิธีคิดผมจากการเขียนคำสั่งสั่งคอมพิวเตอร์ทีละบรรทัด (Imperative)
ให้กลายเป็นการมองหา “Function” ที่เชื่อมโยงระหว่าง A ไป B อย่างตั้งใจ (Equational Reasoning)

แทนที่จะเขียนโค้ดแบบเดาทางไปเรื่อยๆ
ผมเริ่มเปลี่ยนวิธีทำงาน… จากที่เคยเริ่มด้วยการพิมพ์โค้ด
ผมเริ่มจากการ “ออกแบบโครงสร้าง” (Structure & Modeling) ก่อน

พยายามมองให้ออกว่า Domain ของเรามีหน้าตาเป็นยังไง
มี State อะไรบ้างที่เป็นไปได้ (และเป็นไปไม่ได้)

แล้วค่อยลงมือเขียนโค้ดโดยเน้นการ “พิสูจน์ความถูกต้อง” ในระดับ Logic
ให้ได้มากที่สุดเท่าที่จะทำได้ แม้จะยังทำได้ไม่ Perfect 100%
แต่มันทำให้ผมไม่ต้องคอยลุ้น หรือ Log ดูหน้างานพร่ำเพรื่อแบบเมื่อก่อน
เพราะเราได้ออกแบบ Logic และ Structure ให้มัน Make Sense ตั้งแต่ก่อนจะเริ่มพิมพ์โค้ดบรรทัดแรกแล้ว

“เรียน 1 เดือน ย่อย 1 ปี” โคตรไม่เกินจริง

เคยมีผู้เรียนคนหนึ่งกล่าวไว้ในคลาสออนไลน์คลาสนึงที่พี่เดฟเป็นผู้สอนไว้ว่า

“เรียน 1 เดือน แล้วต้องย่อยอีก 1 ปี”

ประโยคนี้แม่งไม่เกินจริงเลยฮะ (ผมเห็นข้อความนั้นแล้วยังกดปุ่ม Emoji ขำ (🤣) ใส่อยู่เลย) … โคตรโดนใจจ๊อดด

ต้องบอกก่อนว่า M4WP เนี่ย มันเป็น Series ยาวนะ
(แบ่งเป็น Episode ละ 2 วัน มีทั้ง Day 0, 1–2, 3–4 ไปยัน Day 7–8)

แต่เอาจริงๆ… แค่ Episode เดียวที่เรียนกัน 2 วันเต็มๆ เนี่ย
ไอ้เนื้อหาที่ดูเหมือนโคตร Abstract (อย่างพวก Set, Logic, Category Theory)
แม่งเล่นเอาคนพื้นฐานไม่แน่นอย่างผม ถึงกับสมองน็อกเป็นปลาน็อกน้ำ
หลับกลางอากาศไปในช่วงบ่ายเลยทุกครั้ง 🤣
(ผมเป็นเด็กสายอาชีพเก่า ที่คณิตศาสตร์ลากเลือดมาตลอด)

แต่เชื่อมั้ยว่า… ไอ้สิ่งที่อัดเข้าไปตอนนั้น…

“พวกมันคือยาขมที่ค่อยๆ ออกฤทธิ์”

มันต้องใช้เวลาค่อยๆ ย่อย ค่อยๆ ปรับจูนสมองที่เคยชินกับการ “เขียนโค้ดให้เสร็จๆ ไป” ให้กลายมาเป็นสมองที่ “มองหาโครงสร้างและความเป็นเหตุเป็นผล”

โดยส่วนตัวแล้ว แต่ละ Episode ที่เรียนไป ผมใช้เวลาย่อยอย่างน้อย 3 เดือน
(ยกเว้น Day 0 ที่ยังเป็น Intro ปูพื้นฐานนะ
อันนั้นยังพอเข้าใจได้ง่ายหน่อย แต่หลังจากนั้นคือของจริง…)
และผมประมาณเอาไว้ว่ายังเข้าใจไม่ถึง 20% ของสิ่งที่ได้จากการเรียน M4WP ด้วย
แต่แค่นี้ผมก็รู้สึกว่าคุ้มค่าที่ลงทุนเวลาไปกับสิ่งนี้แล้วล่ะ

ผมเคยคิดเล่นๆ ว่า ถ้าชาตินี้ผมพยายามจนเก็บเกี่ยวความรู้ได้สัก 15-20% ของแก
สำหรับผม… นั่นคือการเติบโตที่ผมภูมิใจที่สุดในฐานะ Programmer คนนึงแล้ว
(และผมจะพยายามไปให้ถึงจุดนั้นให้ได้ฮะ 😉)

สิ่งที่ AI ให้ไม่ได้… คือ “รากฐาน” ของวิธีคิด

ทุกวันนี้ แม้เราจะอยู่ในยุคที่คนเก่งๆ เขาใช้ AI ช่วย Generate Code ได้ภายในไม่กี่นาที
แต่ “รากฐาน” ทางความคิดเหล่านี้ คือสิ่งที่ AI ให้ไม่ได้

มันทำให้ผมกลายเป็นคนที่ “แก้ปัญหาอย่างเป็นระบบมากขึ้น”
โค้ดที่ออกมาจึงคาดเดาได้, และสะท้อน Logic ของโลกความเป็นจริง
และเป็นโค้ดที่สามารถใช้สื่อสารกับ business person ได้เข้าใจง่าย
แทนที่จะเป็นโค้ดที่เต็มไปด้วย if-else, try-catch ซ้อนกันยุ่บยั่บจนอ่านไม่รู้เรื่อง

พอนึกถึงคำว่า “รากฐาน” ภาพเหตุการณ์นึงในอดีตก็แว้บเข้ามาในหัวผมทันที…

ย้อนกลับไปช่วงแรกๆ ที่ผมเริ่มหัดเขียนโปรแกรม
ผมมีโอกาสได้ไปอาศัยอยู่กับครอบครัวของพี่ชายท่านแรกที่ผมเอ่ยถึง
พี่เขาหวังดี อยากปั้นให้ผมเป็นลูกมือช่วยงานแก
แกเคี่ยวเข็ญผมหนักมาก… เรียกว่า “นรกแตก” เลยก็ว่าได้

ผมนั่งฝึกเขียนโค้ดวันละ 10–14 ชั่วโมง ทุกวัน!
ติดต่อกันร่วม 3 เดือน แต่ด้วยความที่หัวช้า (และพื้นฐานเป็นศูนย์)
แค่ Loop ง่ายๆ ผมยังไม่เข้าใจ logic ของมันเลย
เขียนโค้ดทีไรก็โดนพี่เขาดุประจำ (บางทีก็เขกมะเหงกให้ด้วย) ประมาณว่า

“มึงชอบใช้แต่ทางลัด ชอบท่องจำ แต่ไม่ยอมทำความเข้าใจ”

สุดท้าย… ผมไปต่อไม่ไหว สมองผมรับ Load ขนาดนั้นไม่ได้
จนต้องเก็บข้าวของระเห็จออกจากบ้านแกมา

ออกตัวไว้ก่อน
ที่จริงพี่เขาใจดีนะ เดี๋ยวหลายคนอ่านแล้วเข้าใจผิดว่าทำไมโหดร้ายกันขนาดนี้ 🥹
เขาสอนให้ทั้งการเขียนโปรแกรมทั้งเรื่องการใช้ชีวิต

ทั้งยังได้ซึมซับแนวคิดเรื่อง FP จากแกมาเป็นต้นทุนช่วยในหลายปีถัดมา
โดยที่แกไม่เคยพูดคำว่า FP หรือ Jargon ของมันเลยแม้แต่คำเดียว!

แต่ในช่วงเวลาที่อยู่ที่นั่น นอกจากเรียนโค้ด
ผมก็ต้องช่วยงานบ้านแลกข้าวแลกน้ำ กวาดบ้าน ล้างจาน
ไปจนถึงช่วยงานใช้แรงอย่างการทำสวน

มีอยู่วันหนึ่ง ในช่วงบ่ายที่อากาศกำลังสบาย (แต่เหงื่อผมท่วมตัว)
ผมกำลังช่วยแกขุดรากต้นไผ่ไปทิ้งจนเสร็จ…
พี่เขาชวนผมเดินพักเหนื่อยคุยกันในหมู่บ้าน
บทสนทนาวันนั้นดูเรียบง่าย
แต่มีประโยคหนึ่งที่แกย้ำกับผม (เป็นครั้งที่ร้อย) ว่า…

“มึงจำไว้นะ… ทำอะไรพยายามอย่าใช้แต่ทางลัด
ถ้าบ้านมึงตอกเสาเข็มวางรากฐานไม่ดี
วันนึงบ้านมึงจะพังทลายลงมาทั้งหลัง”

ตอนนั้นผมฟังแล้วก็พยักหน้าช้าๆ ว่าเข้าใจ แต่ในใจแอบคิดไปว่า…

“รอดแล้วตรู… โชคดีนะเนี่ยที่ตรูอาศัยนอนใต้สะพานลอย ถึงบ้านพังก็ไม่ทับหัว” 🤣

ตัดภาพกลับมาวันนี้… หลังจากผ่านคลาสของพี่เดฟ
และผ่านประสบการณ์ทำงานด้าน Software มาพักใหญ่
ผมเข้าใจแล้วครับว่า ทั้งพี่เดฟ และพี่ชายท่านนั้น
พวกเขากำลังสอนสิ่งเดียวกัน ซึ่งก็คือ

“ความเชื่อมั่นในการสร้างรากฐานที่แข็งแกร่ง”

ในวันที่เราต้องสร้างตึกระฟ้า (Software ที่ซับซ้อน)
ทางลัดอาจจะพาเราไปถึงชั้น 2, 3, …, 5, …, 10 ได้ไว

แต่ทางลัด…ไม่มีทางพาเราไปถึงชั้นที่ 100
โดยที่ตึกไม่ถล่มลงมา

ใครที่ทำงานสายนี้ และรู้สึกว่าตัวเองกำลัง “ตัน”
หรือรู้สึกว่าโค้ดที่เขียน (ด้วย AI) มัน “Fragile” (เปราะบาง) เหลือเกิน
ลองมาเรียนคลาสนี้กันดูครับ (Mathematics for Working Programmers)
หรือติดตามพี่เดฟ (Dave Rawitat Pulam) ได้บน Facebook ฮะ

ผมเชื่อว่าคุณจะมองเห็นโลกของ Software ไม่เหมือนเดิมอีกเลย

.

ปล. ผมเริ่มเรียนคลาสนี้ (รวมถึงคลาสอื่นๆ) ของพี่เดฟมาสักพักใหญ่ๆ แล้ว
แต่ยังไม่เคยได้เขียนรีวิวเลยสักคลาส นี่เป็นครั้งแรกที่เขียนถึง
เพราะมันดีจริงๆ จนอดที่จะบอกต่อไม่ได้ฮะ

หวัดดีปีใหม่ทุกคนเลยนะครับ
ขอให้มีความสุขตลอดปี 🙇🏻‍♂️

Sometimes I work with IntelliJ themes that make it really hard to see which file (in Navigation panel) I’m currently working on.
The background color of the active file is too subtle.
It doesn’t have enough contrast with other files in the navigation panel.

This makes me annoyed because I like to look at files near my current file.
But I can’t find them easily.
I waste time trying to figure out which file I’m actually working on.

See the image below — can you spot the working file?

The problem gets worse on my second monitor.
I use a blue light filter and also use low brightness on that screen to protect my eyes.
The filter makes the color even more subtle.
I literally cannot see any difference between the working file and normal files at all.

What Are the Solutions?

I found three ways to fix this:
Solution 1: Just use another theme!

Solution 2: Be a good citizen — open a PR to fix the theme
We could discuss this with our favorite theme maintainer.
Then submit a Pull Request to improve the default colors.
This helps everyone using the theme!

Solution 3: Quick fix — change the color ourselves in settings
I love my Carbon theme too much to switch to anything else.
And I need this fixed today, not after a PR review process (which might not even get approved).

So I went with solution 3.
Problem solved in 30 seconds.

How to Change the Working File Background Color

Here’s the step-by-step process:

1. Open “Settings” (press CMD+, on Mac or CTRL+, on Windows)
2. Click on “Appearance & Behavior” in the left sidebar
3. Click on “File Colors”
4. Find and select “Open Files” from the scopes list
5. Choose any color you prefer (I picked “Rose” for now - it must be bright enough)

The Result

Let’s see how it looks now:

Perfect! Now all my open files have a rose background color.
My current working file is HedgingConfiguration.kt.
We can see it has both the rose color AND the selected file highlight on top of it.

Is it pretty? No.
Does it work? Absolutely! 😂

The good news is I can always customize the “Open Files” background color again later if I want something less ugly.
But for now, this setup saves my life.
I can finally see which file I’m working on without wasting time.

If we face the same problem, give this trick a try!
It takes just 30 seconds to set up.

Bonus Tip: Auto-Select Our Working File

Click the three-dot menu at the top of the navigation panel.
Enable “Always Select Opened File”.

Now IntelliJ automatically scrolls to your current file and highlights it in the tree.
No more manual scrolling to find where you are.
It’s a perfect combo with your new background color!

Thanks for reading until the final line.
If you’re confused or have any questions, don’t hesitate to leave the comments.

Feel free to connect with me and stay updated on the latest insights and discussions.
👉 https://linkedin.com/in/fResult 👈

I’m working on a small practice project based on Josh Long’s Reactive Spring book.

Reactive Spring

I made many little changes, and it’s hard to track them all by hand.
So I use an AI to draft my PR description for later review/revisit.

We can use this on any PR we open for code review

Here are the steps I took:

1. Capture the diff

I run:

git diff source/main...HEAD > changes.diff

# Generic version
git diff [«remote_name»/]«base_branch»...«checked_out_commit» > «target_file»

• source is my remote name (yours might be origin or something else)
• main is the branch we compare against (Don’t make changes to main directly on your real work 😂)
• changes.diff holds every code change since that branch

You can also run:

git diff origin/development...HEAD > changes.diff
# OR
git diff origin/feature/xyz...HEAD > changes.diff

Here’s what our git remote -v looks like in this repo:

➜ git remote -v
origin  git@gitlab.com:fResult/learn-spring-webflux-3.0.git (fetch)
origin  git@gitlab.com:fResult/learn-spring-webflux-3.0.git (push)
source  git@github.com:fResult/Learn-Spring-Webflux-3.0.git (fetch)
source  git@github.com:fResult/Learn-Spring-Webflux-3.0.git (push)

Our diff looks like this:

https://gist.github.com/fResult/bf98b1fc574c7bf452d2a8c48f6b95ba#file-changes-diff-L88-L127

2. Paste into an AI tool with a prompt

We open our favorite AI (ChatGPT, Claude, Gemini…) and paste the diff:

[[Paste the diffs from your `changes.diff` file here]]

Hey, bro!
From above, I just opened a new GitHub Pull Request with these changes.
Could you help me summarize what’s been modified in this PR?

[[Add your background and/or special commands]]

The special commands I added are…

.
.
A bit of background:
- This is part of a practice project I built while following "Reactive Spring", authored by Josh Long.
- I was curious about retry logic and built a small Kotlin DSL for exponential backoff.

Please remember,
this is just for personal reference,
not a release note, so don't make it too formal!

Note:
We can say:
“This is just for the code reviewer, not a release note, don’t make it too formal!”

3. Review the AI’s summary

Please check carefully, it can make things wrong.

The AI might return something like this:

# Lesson 08: Raw RSocket sub-project (Bidirectional, Metadata)

## What’s in this batch of changes?

- **README tweaks**  
    - Added notes on Gradle Kotlin-DSL quirks (type-safe vs. string deps, afterEvaluate, plugin `apply(false)`)
- **Build updates**  
    - Pulled in `jackson-module-kotlin` so our data classes actually deserialize  
    - Added Netty’s macOS ARM DNS resolver to silence the native-lib warnings
- **EncodingUtils cleanup**  
    - Switched metadata reader to a proper `TypeReference<Map<String,Any>>`  
    - Hoisted duplicate exception‐handling into one helper  
    - Removed the extra `ObjectMapper` bean—only `EncodingUtils` now
- **Retry DSL**  
    - New tiny DSL under `dsl.retry`: `RetryConfig`, `RetryConfigBuilder`, and a `retryBackoffOnClosedChannel { … }` factory  
    - Client now does `.retryWhen(retryBackoffOnClosedChannel { maxAttempts = 5 })` with backoff + jitter + ClosedChannel filter
- **Bidirectional RSocket example**  
    - New raw-rsocket modules for server & client (DTOs, launcher, service)  
    - Client launcher refactored to named handlers (`onGreetingReceived`, `onGreetingError`, `onGreetingComplete`)  
    - Service now logs “Finished greeting to <clientId>.” so you know which client ended
- **Misc**  
    - Added Gradle `bootBidirectionalService` & `bootBidirectionalClient` tasks  
    - Cleaned up some unused imports in Fire-and-Forget example

Basically just personal clean-ups and a small retry DSL on top of the book’s starting code.

Read it! Update any details, and drop it into our PR.

Now, anyone who reviews our code, or even we ourselves, month after month, can quickly see what we did and why.

Tip:
Always glance over the AI’s output.
Make sure it reflects exactly what we did and our thoughts.

See my Pull Request:

Lesson 08: Raw RSocket sub-project (Bidirectional, Metadata) by fResult · Pull Request #20 · fResult/Learn-Spring-Webflux-3.0

Happy coding, PR writing, and documenting!

Appendix

To see all changes since branching off the base branch:

git diff [«remote_name»/]«base_branch»…HEAD > changes-since-base.diff

To see the diff of staged files (added with git add) against HEAD:

git diff --staged > changes-staged.diff

To see the diff of working tree changes (not yet staged) against HEAD:

git diff HEAD > changes-working.diff

In case you use OSX, you can copy diffs to the clipboard directly:

git diff --staged | pbcopy

Thanks for reading until the final line.
If you’re confused or have any questions, don’t hesitate to leave the comments.

Feel free to connect with me and stay updated on the latest insights and discussions.
👉 https://linkedin.com/in/fResult 👈

Table of Contents

• ยาวไป…ไม่อ่าน
• Main Content
• Conclusion & Final Thought
• Appendix (ตรงนี้ Code ยาวจัด… ไม่ต้องอ่านก็ได้ครับ)

ยาวไปไม่อยากอ่านอะ (มาอ่านสั้นๆ ตรงนี้ได้เลยฮะ)

ถึงแม้ Java ไม่มี Union Type แบบภาษาอื่น
แต่เราสามารถจำลองมันได้ด้วย sealed interface ร่วมกับ record หรือ class ได้นะ
ซึ่งจะทำให้ compiler ช่วยตรวจจับ error ได้แต่เนิ่นๆ โดยไม่ต้องรอให้ code พังตอน runtime (ได้รับ fast feedback loop) และช่วยลดการเขียน Method Overloading ในภาษา Java ได้ฮะ

ตัวอย่าง:

// Mimick TypeScript's Union Type like declaring `type Result = Success | Failure`
sealed interface Result<S, E> permits Success, Failure {}
record Success<S, E>(S value) implements Result<S, E> {}
record Failure<S, E>(E error) implements Result<S, E> {}

record User(String name) {}

public String handle(Result<User, NotFoundException> result) {
  return switch (result) {
    case Success<User, NotFoundException> s -> "Found user: " + s.value().name();
    case Failure<User, NotFoundException> f -> "[ERROR]: " + f.error().message();
  };
}

handle(new Success(new User(/*name:*/ "John")); // Found user: John
handle(new Failure(new NotFoundException("User with name [John] not found!")); // [ERROR]: User with name [John] not found!

ตัวอย่างจากเนื้อหาหลักจะ Simple กว่านี้ (มั้ง) นะ 😅

Main Content

ในบทความนี้เป็นบันทึกแบบสั้นๆ ที่ผมบังเอิญนึกขึ้นได้ในระหว่างกำลังอ่านๆ เกี่ยวกับ Type-Level Programming in Scala อยู่เพลินๆ ก็แว่บไอเดียว่านี่มันมีความคล้ายกับ Union Type ในภาษา TypeScript ที่คุ้นเคยอยู่เหมือนกันนะเนี่ย

Type-Level Programming in Scala: Part 1 - Numbers and Comparisons

และเนื่องจากเคยมีคำถามที่ติดใจกับตัวเองมาตลอดว่า ทำไม Java/Kotlin ถึงไม่ทำ Union Type แบบ TypeScript บ้างน้าาา?

และเรื่องที่อ่านเจอนี้ก็มีความใกล้เคียงกับ TypeScript ซะด้วย งานนี้คงไม่ลองไม่ได้แล้วล่ะฮะะ

เมื่อก่อนผมดีลกับ Kotlin/Java ได้ยังไงในเคสที่ต้องการทำงาน Union Type?
คำตอบก็คือผมใช้ Method Overloading แทนฮะ

คิดได้ดังนั้นก็เปิด IntelliJ สิครับ (ไม่ขอรอประธานที่ไหนมาตัดริบบิ้นให้ทั้งนั้น 555)

เริ่มจากประกาศ Permissionให้ Read และ Write sealed record classes เสียก่อน
(ที่จริงแล้วไม่ต้อง sealed record classes แต่อาจเป็นแค่ interface และ classes ก็ได้นะ)

sealed interface Permission permits Read, Write {}
record Read() implements Permission {}
record Write() implements Permission {}
record Execute() {};

Note:
จากข้างบน ผมจงใจไม่ใส่ implements Permission interface ให้กับ Execute record class เพื่อเอาไว้ทดสอบเรื่อง type-safety ในภายหลังนะฮะ

Read, Write record class ซึ่ง implement จาก Permission interface ก็จะเลียนแบบการทำงานของ Union Type ใน TypeScript ประมาณนี้ล่ะมั้งนะ

type Permission = Read | Write

type Read = {}
type Write = {}

จากนั้นก็ประกาศ method ที่ต้องการให้รับ parameter ได้ทั้ง Read และ Write แบบนี้

class ResourceAction {
  public String perform(Permission permission) {
    return String.format("Performing action with %s...", permission.getClass().getSimpleName());
  }
}

และเราจะปิดท้ายด้วย main method

class TestSecureResource {
  public static void main(String[] args) {
    final var resourceAction = new ResourceAction();
    System.out.println(resourceAction.perform(new Read()));    // Performing action with Read...
    System.out.println(resourceAction.perform(new Write()));   // Performing action with Write...
    System.out.println(resourceAction.perform(new Execute())); /* Compilation Error!!!!
                                                                * Required Type: Permission
                                                                * Provided: Execute
                                                                */
  }
}

และเราจะเห็นได้ว่า บรรทัดที่เรา assign instance ของ Execute record class ให้เป็น argument ของ ResourceAction::perform method นั้นจะติด Compilation Error ในทันที เนื่องจากไม่ผ่าน type constraint validation นั่นเองฮะ

ต่อไปนี้เป็นตัวอย่างที่นำไปใช้ทดลอง run ได้เลยครับ

ในไฟล์แรก เป็น code ตามในบทความนี้
ส่วนในไฟล์ที่ 2 เป็น code ที่ผมลอง POC เล่นไปเรื่อยเปื่อย 😂

Conclusion

การนำแนวคิดนี้ไปใช้ช่วยให้ Java สามารถจัดการชนิดข้อมูล (Type Constraints) ในลักษณะที่คล้ายกับ Union Type ใน TypeScript ได้
ถึงแม้ว่า Java จะไม่มี feature นี้มาให้โดยตรงก็ตามด
แต่ด้วยการใช้ Sealed Interface และ Generic Type Constraints (อย่างที่เห็นใน Permission interface)
จะช่วยให้เราลดการเขียน Method Overloading (เช่น perform(Read), และ perform(Write) แยกกัน) ซึ่งทำให้ code เราสะอาดขึ้น และยังคงได้ประโยชน์จาก Type Safety ฮะ

Final Thought

และแน่นอนว่า เมื่อเราจัดการ Logic บางอย่างในระดับ Type-level
ก็ยังช่วยให้เราสร้างระบบที่มี Type System ที่แข็งแกร่งและปลอดภัยมากขึ้นได้
เพราะเราจะได้ตรวจสอบความถูกต้องได้ตั้งแต่ Compile-Time และไม่ต้องไปลุ้นเอาตอน Runtime ให้ปวดหัวนั่นเองฮะ (หมายความว่าเราจะได้รับ fast feedback ซึ่ง IDE จะแจ้งเตือนให้เราแก้ไขทันที)
แบบนี้มันก็จะช่วยลด bug และเพิ่มความมั่นใจในการเขียน code ไปได้เยอะเลยนะ ว่ามะ?

สำหรับวันนี้ขอตัวไปก่อนล่ะฮะ

สวัสดีครับ 🙇‍♂️

Thanks for reading until the final line.
If you’re confused or have any questions, don’t hesitate to leave the comments.

Feel free to connect with me and stay updated on the latest insights and discussions.
👉 https://linkedin.com/in/fResult 👈

And happy coding 🫰🫰

Appendix

ส่วนนี้จะเป็น Code ที่ผมได้ลอง Type-Level Programming แบบเต็มข้อในภาษา Java ดู ท่านใดที่สนใจก็ตามมาตำกันได้เลยฮะ (ใครใคร่ลอง… copy ไปลองได้เลย)

https://gist.github.com/fResult/77c4341a49f8135ea8762b84b3d7fffe

แต่ไม่ต้องดูก็ได้นะ…. เพราะว่า code ยาวจัดๆ เลยครับ 🤣

อันนี้เป็น Code as a Glimpse (เอามาใส่ไว้ให้ดูแบบผ่านๆ ได้):

sealed interface Task permits Todo, Doing, Done;
record Todo(Long id, String title, String description) implements Task;
record Doing(Long id, String title, String description) implements Task;
record Done(Long id, String title, String description, Instant completedAt) implements Task;

class TaskUseCase {

  public TaskResponse advanceTask(Long id) {
    return executeTaskOperation(id, taskManagement::advanceTask);
  }

  public TaskResponse revertTask(Long id) {
    return executeTaskOperation(id, taskManagement::revertTask);
  }

  public TaskResponse markAsDone(Long id) {
    return executeTaskOperation(id, taskManagement::markAsDone);
  }

  public TaskResponse resetToTodo(Long id) {
    return executeTaskOperation(id, taskManagement::resetToTodo);
  }

  private TaskResponse executeTaskOperation(Long id, Function<Task, Task> operation) {
    return taskRepository.findById(id)
        .map(operation.andThen(taskRepository::save).andThen(TaskResponse::fromDomain))
        .orElseThrow(throwNotFound(id, Task.class));
  }
}

class TaskManagement {
  public Task advanceTask(Task task) {
    return switch (task) {
      case Todo(Long id, String title, String description) -> new Doing(id, title, description);
      case Doing(Long id, String title, String description) -> new Done(id, title, description);
      case Done ignored -> task;
    };
  }

  public Task revertTask(Task task) {
    return switch (task) {
      case Done(Long id, String title, String description, Instant ignored) -> new Doing(id, title, description);
      case Doing(Long id, String title, String description) -> new Todo(id, title, description);
      case Todo ignored -> task;
    };
  }

  public Task markAsDone(Task task) {
    if (task instanceof Done) return task;

    return new Done(task.id(), task.title(), task.description());
  }

  public Task resetToTodo(Task task) {
    if (task instanceof Todo) return task;

    return new Todo(task.id(), task.title(), task.description());
  }
}

แต่จากบรรทัดนี้เป็นต้นไป…จะไม่มีการ glimpse แล้วนะ 😂