JDriven Blog

Lazygit

2026-04-17T04:30:00.000Z

Arguably the most popular version control system is Git. Many developers use the command-line version alongside a Git plugin in their favorite IDE. Now those work just fine, but did you know there is also a very nice TUI (Text-based User Interface, alternately Terminal User Interface) for Git called Lazygit. It is a very cool tool. Read on for more information.

How to Start and Install

After installation it starts really fast, just type lazygit in the your terminal in your project directory and you get something like this:

Figure 1. Lazygit Screenshot

Usage

As you can see it gives a very nice overview of your Git workflow and repository status. And as with any TUI navigating and executing commands can be done extremely quickly and easily using your keyboard only (see keybindings). The keybindings can also be popped up with the '?' key. On top of that Lazygit also responds to your mouse.

Figure 2. Lazygit Keybindings

Conclusion

All in all, it is a very handy tool and a great addition to Git on the command-line and your IDE Git plugin.

PKI in a Nutshell

2026-04-14T05:30:00.000Z

This blog briefly describes theoretically how Public Key Infrastructure (PKI) works. It also introduces the key concepts used in PKI. This is done by describing encryption, decryption, hashing, signing, and authentication using mathematical notations.

PKI in a Nutshell

Intro

Given an asymmetric encryption algorithm E and accompanying Decryption algorithm D. It uses a key pair (K_e, K_d) to encrypt a plain text message x into a cipher text y.

encryption: E(K_e, x) = y
decyption: D(K_d, y) = x

Alice and Bob

Suppose Alice and Bob want to exchange encrypted messages with each other, and they also want to sign the messages so that they can be sure the messages they receive are from each other indeed, and not from some malignant third party.

Alice owns two key pairs.

keyPairA1 ={K_A1e, K_A1d}
keyPairA2 = {K_A2e, K_A2d}

Alice publishes the keys K_A1e and K_A2d.

Bob thas two key pairs as well:

keyPairB1 = {K_B1e, K_B1d}
keyPairB2 = {K_B2e, K_B2d}

And he publishes K_B1e and K_B2d.

The keys that are published are called public keys, the ones you keep for yourself are called private keys.

Key pairs are kept in a keystore. Trusted public keys, or the certificates thereof (see below), are kept in a truststore.

Encryption

Bob can now send an encrypted message to Alice using her public encryption key K_A1e with

E(K_A1e, x) = y

Which can only be decrypted by Alice with her private decryption key K_A1d

D(K_A1d, y) = x

And vice versa Alice can send encrypted message to Bob using the public key K_B1e from Bob.

Signing

Bob can use his private signing key K_B2e to sign his encrypted messages.

Given a hashing algorithm H

h = H(y) = hash of y

Next define

s = S(y) = E(K_B2e, H(y)) = signature

Bob sends (y, s) to Alice.

Now Alice can verify the cipher text y is from Bob by applying the verify operation V using Bob’s public verification key K_B2d

V(s) = D(K_B2d, s) = h

And she can also calculate h herself from the received y. Both hashes must be equal. Since only the owner of K_B2e could have sent the signature s encrypted in this way she knows this message is from Bob.

NB The same is true if Bob had signed the plain text x instead of the cipher text y. The choice is somewhat arbitrary. Albeit, that signing the cipher text y is a bit safer. Because when signing x and Alice’s private key has somehow been acquired by a malignant third party Mallory, Mallory can decrypt y and reencrypt it with his own private key and reuse the signature. When y is signed, he cannot reuse the signature.

Vice versa Alice can sign her message to Bob using her signing key K_A2e.

Certificates

What if Alice and Bob have no secure channel to exchange their public keys? Well suppose they do both have a secure channel with a third party CA (Certification Authority) whom they trust, which means they trust the CA’s public verification key K_CAd. They offer their public keys to CA to have them signed.

For example Alice offers her public encryption key to be signed by CA

S_CA(K_A1e) = E(K_CAe, H(K_A1e)) = s_A1e

And Alice publishes

c_A1e = {K_A1e, S_CA(K_A1e)} = {K_A1e, s_A1e} = certificate of K_A1e signed by CA

Bob can now verify the key is from Alice by calculating

V_CA(s_A1e) = D(K_CAd, s_A1e) = h_v

and

H(K_A1e) = h

The following should be true: h_v = h

The same can be done for the other public keys of Alice and Bob. So by publishing certificates of their public keys instead of the keys alone they can safely exchange messages without having a secure channel to exchange their public keys directly.

For convenience CA does not publish its verification key alone, but a self-signed certificate of it

c_CAd = {K_CAd, S_CA(K_CAd)}

Chain of Trust

Above is an example of a chain of trust. Alice and Bob trust CA. This a chain of length 2. Longer chains are more common. For example when Alice and Bob use a certificate from CA₂, which is signed by CA₁, which is signed by a self-signed certificate of CA₀=CA_root. They both trust CA₀, and Alice has her keys signed by CA₂. For example the chain for her public encryption key:

c_A1e = {K_A1e, s_A1e} = {K_A1e, S_CA2(K_A1e)}

c_CA2d = {K_CA2d, s_CA2d} = {K_CA2d, S_CA1(K_CA2d)}

c_CA1d = {K_CA1d, s_CA1d} = {K_CA1d, S_CA0(K_CA1d)}

c_CA0d = {K_CA0d, s_CA0d} = {K_CA0d, S_CA0(K_CA0d)}

So Bob trusts the public encryption key of Alice, K_A1e, because it is signed by CA₂, which is signed by CA₁, which is signed by CA₀, which he trusts.

It is common practice to send the entire chain upon publishing/sending of one’s certificate. So usually one keeps the entire chain for each certificate in one’s keystore. Since the public key is part of the certificate a keystore usually contains entries with in it a private key and the associated certificate chain.

The certificates one trusts are kept a so called truststore. The sender’s chain of certificates must end at a certificate in one’s truststore.

Nushell Niceties: Bumping Semantic Version

2026-04-14T04:52:23.000Z

In a previous blogpost you can learn about the semver command in Nushell to transform a string value into a semver type. With the semver bump command you can increase one of the components of the semver type. For example to increase the major version part you can use semver bump major. This command will also update the minor and patch parts if needed. The result is a semver type and you can use into value to transform it to a string type.

In the following example several of the semver bump commands are used:

use std/assert

# After installing the nu_plugin_semver plugin and
# adding it to the plugin registry you can use
# the plugin for Nushell code.
plugin use semver

# Transform string to semver value.
let version = '4.0.2'

# Bumping major part of version by adding 1 to the current value.
assert equal ($version | semver bump major | into value) '5.0.0'

# Bumping minor part by adding 1 to the value.
# The option `--ignore-errors` makes sure when an error occurs the
# original input value is returned. The shorthand `-i` is also valid.
assert equal ($version | semver bump minor --ignore-errors | into value) '4.1.0'

# Bumping patch part by adding 1 to the value.
assert equal ($version | semver bump patch | into value) '4.0.3'

# Bumping to a release candidate version, patch is unchanged.
assert equal ($version | semver bump rc | into value) '4.0.2-rc.1'

# Bumping to a next alpha version by adding 1 to patch value and
# pre-release part `alpha.1`.
assert equal ($version | semver bump alpha | into value) '4.0.3-alpha.1'

# Bumping to a next beta version by adding 1 to patch value and
# pre-release part `beta.1`.
assert equal ($version | semver bump beta | into value) '4.0.3-beta.1'

# Using `bump release` will remove the pre (release) part of semver value.
assert equal ('4.0.3-rc.1' | semver bump release | into value) '4.0.3'


# The same bump commands can be used for a semver type input.
let full_version = '4.0.2-rc.1+build-20260205' | into semver

assert equal ($full_version | semver bump major | into value) '5.0.0'
assert equal ($full_version | semver bump minor | into value) '4.1.0'
assert equal ($full_version | semver bump patch | into value) '4.0.2+build-20260205'
assert equal ($full_version | semver bump rc | into value) '4.0.2-rc.2+build-20260205'
assert equal ($full_version | semver bump release | into value) '4.0.2+build-20260205'


# The `semver bump` command support the `--build-metadata` (or shorthand `-b`)
# option to add build metadata to a semver or string value.
(assert equal
        ('4.2.8' | semver bump minor --build-metadata 'build-20260205' | into value)
        '4.3.0+build-20260205')

Written with Nushell 0.111.0.

Original post

Nushell Niceties: Transform Values Into Semver Types

2026-04-07T04:45:40.000Z

Nushell can be extended with plugins to have more functionality or types that are not part of standard Nushell. If you want to work with string values that are actually semantic version values (https://semver.org) you can use the Nushell SemVer plugin. The plugin must be added to Nushell by using the command plugin add <location of plugin>. You can check with plugin list command if the plugin is available. This command also shows commands that the plugin adds to Nushell.

The command into semver can be used to convert string values into a semver type. The semver type has 5 properties: major, minor, patch, pre and build. You can use dot notation to get the values for these properties or use the get command. In the following command a string value is transformed to a semver type: let v = '4.0.2' | into semver. And with $v.major you can extract the major part of the semver value and it returns 4.
Records with the keys major, minor, patch, pre and build can be transformed to a semver string with the semver from-record command. And to transform a semver type to a record you can use the command semver into-record.

In the following example different string values are transformed and from a semver type or record:

use std/assert

# After installing the nu_plugin_semver plugin and
# adding it to the plugin registry you can use
# the plugin for Nushell code.
plugin use semver

# With `into semver` you can transform a string
# into a semver value with the fields
# major, minor, patch, pre and build.
let version = '4.0.2' | into semver

assert equal $version.major 4
assert equal $version.minor 0
assert equal $version.patch 2
assert equal ($version | get patch) 2

# Type is semver and no longer a string type.
assert equal ($version | describe) semver

# A full version with all parts.
# The pre (release) part is after the patch and - up until the +.
# The build part is everything after the +.
let full_version = '4.0.2-rc.1+build-20260205' | into semver

assert equal $full_version.major 4
assert equal $full_version.minor 0
assert equal $full_version.patch 2
assert equal $full_version.pre 'rc.1'
assert equal $full_version.build 'build-20260205'

# A version with major, minor, patch and build part.
let build_version = '4.0.2+build-20260205' | into semver

assert equal $build_version.build 'build-20260205'
assert equal $build_version.major 4
assert equal $build_version.minor 0
assert equal $build_version.patch 2


# Using `semver to-record` to transform a semver value or string
# to a record with the keys major, minor, patch, pre and build.
assert equal ($version | semver to-record) {
    major: 4 minor: 0 patch: 2 pre: '' build: ''
}
assert equal ('1.2.3' | semver to-record) {
    major: 1 minor: 2 patch: 3 pre: '' build: ''
}
assert equal ('4.0.2-rc.1+build-20260205' | semver to-record) {
    major: 4 minor: 0 patch: 2 pre: 'rc.1' build: 'build-20260205'
}

# Using `semver from-record` to transform a record with keys
# major, minor, patch, pre and build to a semver value.
(assert equal
        ({major: 4 minor: 0 patch: 2 pre: '' build: ''} | semver from-record)
        '4.0.2')
(assert equal
        ({major: 4 minor: 0 patch: 2 pre: 'rc.1' build: 'build-20260205'} | semver from-record)
        '4.0.2-rc.1+build-20260205')


# A list of string value can be transformed to a list of semver values.
(assert equal (['4.0.2-rc.1+build-20260205' '1.2.3'] | into semver)
    [('4.0.2-rc.1+build-20260205' | into semver) ('1.2.3' | into semver)])

Written with Nushell 0.110.0.

Original post

Battle-testing Temporal - Part 3

2026-03-31T20:00:00.000Z

In part 3 of this series about Temporal it is finally time to explore cross-workflow creation, communication & orchestration. Upgrading the poker use-case from single-table to supporting multi-table tournaments of arbitrary size.

Diving into:

How to spawn child workflows and their intended behavior
Using signals to communicate between workflows
Set up a Tournament workflow orchestrating Table workflows

(See here for part 2)

Spawning Child workflows

From inside any workflow it is possible to create and start child workflows. This is done by creating a specific type of workflow stub using Workflow.newChildWorkflowStub, which takes a slightly augmented set of options.

String tableWorkflowId = String.format("%s-%d", tournamentId, tableNumber);
ChildWorkflowOptions options = ChildWorkflowOptions.newBuilder()
        .setTaskQueue("all_tables")
        .setWorkflowId(tableWorkflowId)
        .setParentClosePolicy(ParentClosePolicy.PARENT_CLOSE_POLICY_ABANDON) // specific for childs
        .build();
TableWorkflow tableWorkflow = Workflow.newChildWorkflowStub(TableWorkflow.class, options);

While PARENT_CLOSE_POLICY_ABANDON sounds ominous, what it means is that when the workflow that started the child workflow is done, the child workflow will be left alone and thus continues to run.

Other options would be to directly terminate it or request a cancellation upon completion of the parent workflow.

The tableWorkflow represents the stub, but just like before its workflow method still need to be called to actually start. From inside a workflow you do not need a WorkflowClient.

Instead, you have the option to directly use the stub, synchronously awaiting its method completion or using the Async class for asynchronous execution.

TableState tableState = TableState.fromInitial(...); // the workflow input

// this calls and blocks until the child is done.
tableWorkflow.workflow(tableState);

// this calls it asynchronously
Async.procedure(tableWorkflow::workflow, tableState);

// returns a promise (useful for non-void workflow methods)
Promise<...> resultPromise = Async.function(tableWorkflow::workflow, tableState);

Clearly for the tournament/table use-case I want to start multiple table workflows asynchronously.

Acquiring long-term stubs

A bit quirky perhaps, but it seems Workflow.newChildWorkflowStub provides a stub to the current first Run of the child workflow. Meaning that whenever a table continues as new, the stub is not suitable to send signals.

Therefore, the tournament workflow uses Workflow.newExternalWorkflowStub directly after starting the child workflows to actually acquire stubs that survive child workflows moving to new Runs.

Which is basically just a get stub by workflow id.

newExternalWorkflowStub can also be used to acquire stubs to any other workflow from inside workflows. I use this to signal the parent tournament workflow from inside the table workflows as well.

Sending signals between workflows

There isn’t much to it when it comes to sending a signal, once you have a stub ready. You can just call any @SignalMethod directly on the stub. With signals being meant to be fast in terms of delivery as well as execution there is no need for asynchronous behavior.

As mentioned before, a workflow process will not even yield when calling a signal method like it does for calling activities. Effectively making it behave like any other plain old java method call.

The tournament/table signals

Having built this use-case before, I already had a pretty good idea of how the flow should look like.

E.g. supporting:

slowly closing of tables as players go bust
tables dealing with new incoming players
ranking players across all tables

Matching it to signal-based parent/child workflow communication felt most natural and turned out to be pretty straight-forward.

The following diagram provides an overview of both the signals between the workflows and the actions (sent as updates) from the client. Depicting a 20-player tournament, but the flow remains the same for any amount of players/tables.

Figure 1. The signals/updates between the components

Once enough players have been ranked (lost their chips), a table can be stopped and once it’s closed any remaining players are moved to other tables. Repeating this process until the last table is closed.

Ranking of players

Zooming in on the code of an incoming signal, in this case the ranking of a player. As signaled from a table workflow.

Note that I followed the practice of capturing signals in queues and having the workflow methods itself deal with the work at the appropriate time.

private final Deque<PlayerToRank> playersToRank = new ArrayDeque<>();

@Override
public void onRankPlayer(PlayerToRank ptr) {
    playersToRank.add(ptr);
}

@Override
public void workflow(TournamentState tournamentState) {
    ...
    while (!playersToRank.isEmpty()) {
        // using the signal receive order as ranking order (counting down)
        rankPlayer(playersToRank.pop());
    }
    ...
}

The Tournament Workflow

Looking a bit deeper into the workflow method of the new Tournament workflow. It is basically responsible for handling the incoming signals from the table workflows when started and Buyins from players before the tournament has started. (Not supporting Rebuys)

It has therefore two specific states, waiting upon start and started. Each state supporting distinctly different signals/updates.

I choose to directly reflect this into the basic structure of the code.

@Override
public void workflow(TournamentState tournamentState) {
    state = tournamentState;

    while (state.getStatus() == WAITING) {
        Workflow.await(() -> incomingWaitingWork());

        while (!playersToAdd.isEmpty()) {
            addPlayerToTournament(playersToAdd.pop());
        }

        if (state.seatsFilled()) {
            startTournament(); // starts the tables as child workflows
        }
    }

    acquireTableWorkflows(); // get the long-term stubs to tables

    while (state.getStatus() == STARTED) {
        Workflow.await(() -> state.getStatus() == DONE || incomingStartedWork());

        while (!playersToRank.isEmpty()) {
            rankPlayer(playersToRank.pop());
        }
        while (!closedTables.isEmpty()) {
            handleClosedTable(closedTables.pop());
        }
    }

    Workflow.await(Workflow::isEveryHandlerFinished);
}

Obviously the client and worker registration should be updated as well to make the whole thing work again, but it is basically just more of the same seen earlier.

Starting a tournament instead of directly starting a table from the client. Acquiring stubs to all tables once the tournament has started:

if (tournamentEvent instanceof TournamentStarted) {
    int tables = ((TournamentStarted) tournamentEvent).tables();
    List<TableWorkflow> tableWorkflows = IntStream.rangeClosed(1, tables)
            .mapToObj(tableId -> client.newWorkflowStub(TableWorkflow.class,
                    String.format("%s-%s", tournamentId, tableId)))
            .toList();
    ...
}

Temporal Child Workflow support

Apart from visualizing the signals/updates and activities, looking at the history dashboard of a workflow also shows when it spawns a child workflow.

Also showing their status and running time.

Figure 2. Tournament workflow with one last table active

Learnings so far

Applying the program flow from a previous event-based iteration of the logic to the temporal based workflow implementation works pretty much 1-to-1. Migration to fast queueing signal handlers again improving overall quality of the code in the process.
Signals are guaranteed to be fed one by one to the workflow in the order they are received and registered into the history. Being used to kafka, this again maps well to my own default metal model.
The visual inspecting a workflow using the Temporal dashboard is quite handy when it comes to debugging and manually confirming correctness of a workflow execution.

Next up…

Stay tuned for more to come as it is time, overdue even, to explore (unit)testing Temporal workflows as well as the first steps towards account management and financial processes like Deposit, Buy-in and Payout.

Battle-testing Temporal - Part 2

2026-03-26T21:00:00.000Z

In part 2 of this series about Temporal I want to dive deeper into some of the details involved in making workflows actually run and run properly.

Diving into:

Starting and communicating with a Workflow
Supporting replay, continueAsNew and early signals
Adding an Activity and hooking it all up together

(See here for part 1)

Starting and communicating with a Workflow

Now that I’ve shown a bit of the basics of how workflow code could look like, it’s time to look at actual code instead of pseudocode before diving deeper.

The most basic version of the workflow looks like this:

@WorkflowInterface
public interface TableWorkflow {
    @WorkflowMethod
    void workflow(InitialTable initialTable);
    @UpdateValidatorMethod(updateName = "onCheck")
    void validateCheck(Check check);
    @UpdateMethod
    void onCheck(Check check);
    ...
}

public class TableHandler implements TableWorkflow {
    private TableState state;
    @Override
    public void workflow(InitialTable initialTable) {
        state = TableState.fromInitial(initialTable);
        while (state.getStatus() != FINISHED) {
            // do stuff
        }
    }
    @Override
    public void validateCheck(Check check) {
        // see part 1
    }
    @Override
    public void onCheck(Check check) {
        // see part 1
    }
    ...
}

As you can see all the Temporal annotations are added to a separate interface.

In order to actually start a workflow you need two things:

a Worker that registers itself as able to run a particular workflow implementation class.
a WorkflowClient to tell Temporal to start the actual workflow using the interface.

Registering the worker

void startWorker() {
    WorkflowServiceStubs serviceStubs = WorkflowServiceStubs.newLocalServiceStubs();
    WorkflowClient client = WorkflowClient.newInstance(serviceStubs);
    WorkerFactory factory = WorkerFactory.newInstance(client);
    Worker worker = factory.newWorker("all_tables"); // <--- the task queue
    worker.registerWorkflowImplementationTypes(TableHandler.class); // <-- the workflow implementation
    factory.start();
}

As you can see its quite flexible, with a worker being able to specify any number of specific workflows that it is able to run. Furthermore, every worker must also specify a task queue, allowing for specific workers to work only for subsets of workflows of the specified workflow type(s). Effectively able to divide work in any number of different ways.

Creating a client and starting a workflow

void startWorkflow(String workflowId) {
    WorkflowServiceStubs serviceStubs = WorkflowServiceStubs.newLocalServiceStubs();
    WorkflowClient client = WorkflowClient.newInstance(serviceStubs);
    WorkflowOptions options = WorkflowOptions.newBuilder()
            .setTaskQueue("all_tables") // same task queue
            .setWorkflowId(workflowId)
            .build();

    TableWorkflow tableWorkflow = client.newWorkflowStub(TableWorkflow.class, options);
    InitialTable initialTable = new InitialTable(...)
    WorkflowClient.start(tableWorkflow::workflow, initialTable);
}

As you can see, you first create a WorkflowClient. Then you request a stub of a certain workflow interface type, specifying any details in the options.

the stub can then be used inside the WorkflowClient.start method to provide a method reference and the appropriate amount of input variables. In an indirect, but fully type-safe way.

Note that apart from newWorkflowStub the following flavors also exist.

newExternalWorkflowStub to communicate to other workflows from inside workflows.

newChildWorkflowStub to start a workflow as a child from within another workflow.

Supporting replay, continueAsNew and early signals

With the basic real-code example laid-out, a few more tweaks are needed to properly support restarting of the workflow. Restarting either as result of a failure or as part of the best-practice to restart the workflow from its current state as checkpoint. To clean up a history that is reaching its size limits.

As with other event-sourced systems, when event history grows too large, non-functional issues start to arise. So it’s best to start from a fresh checkpoint once every while.

Again, the framework gives the user full control over where and when to do this. Even so, there is no way to prevent early signals. Which I noticed specifically happening around replays of workflows. Signals may in fact be fed to a workflow before its @WorkflowMethod has been called. Meaning in this case, the state variable may still be null when inside a @SignalMethod or @UpdateMethod.

So three tweaks are needed:

changing the workflow method to directly accept the TableState in any form
triggering continueAsNew when history becomes to large
dealing with state in @SignalMethod or @UpdateMethod

public class TableHandler implements TableWorkflow {
    private TableState state;

    @WorkflowInit
    public TableHandler(TableState tableState) { (1)
        this.state = tableState; (3)
    }

    @Override
    public void workflow(TableState tableState) { (1)
        while (state.getStatus() != FINISHED) {
            // do stuff

            if (Workflow.getInfo().getHistoryLength() >= 5000) {
                // make sure other methods finished completely
                Workflow.await(Workflow::isEveryHandlerFinished);
                Workflow.continueAsNew(state); (2)
                return; // immediately stop this workflow instance
            }
        }
    }
    ...
}

"not relying on state in @UpdateMethod" proved to be effectively impossible, not being able to validate the user input without knowledge of the state. Conveniently Temporal provides the @WorkflowInit annotation which you can put on the constructor. Effectively switching to the more typical constructor-based state injection to help with simple state always being available.

You can only run simple non-blocking logic in constructors

Its good form to use Workflow.await(Workflow::isEveryHandlerFinished) before signaling to Temporal the workflow should be started fresh from a particular state with Workflow.continueAsNew(state). This is because Temporal will create a new instance of the workflow class providing the given state as input of the workflow method. But any @UpdateMethod that was somehow interleaved half-way and is still not fully finished at this point, will likely be problematic. Therefore, it’s best to use the specific await condition for this.

By keeping all @UpdateMethod free from activities/awaits and just queueing work, no interleaving can happen.

The theoretical maximum history length to check for depends highly on the amount of bytes per recorded event. The default is maximum size 50MB for the entire history. Meaning small events will take you further than large events (and so will binary encoding over the JSON default).

I would recommend using your personal use-case and user-experience with the Temporal Dashboard to guide you to a history size threshold.

Are we hardened yet?

To the best of my knowledge, this workflow is now fully ready to handle (deliberate) restarts and weird edge-cases.

Continued workflows

When looking that the dashboard you can spot continued workflows quite easily:

Figure 1. The same workflow continued into a new Run two times

As you can see, each time it continues from a certain state (checkpoint) a new run is started using a unique Run ID. The concept of a Run is mostly relevant in the context of a client that can either point to the workflow (automatically the active run), or point to a specific Run ID.

Replayed workflows

A workflow that failed or otherwise got killed half-way completion, will automatically be brought back online by the framework whenever a suitable worker is active (again). This is done entirely based on event-sourcing, with the framework restarting the workflow from its initial state following by feeding it all recorded signals. Where applicable during its re-execution instantly returning previously recorded values of things like Workflow.newRandom() or results of recorded calls to activities.

The workflow itself being oblivious to whether or not its being replayed or at what point normal progression resumes.

Idiomatically a workflow that is restarted with a replay also doesn’t count as a new Run, but rather as a continuation of the same run. With the dashboard only showing actual workflow-level errors if any. E.g. stopping and starting a worker mid-process merely resulting in a visible time-gap of progress being made.

Figure 2. A workflow with the worker stopped and started mid-way

Adding the Activity into the mix

While the above example code is now presumed to be properly written, it is not showing the Activity to push events to clients yet.

Using an Activity looks somewhat the same as acquiring a stub to a Workflow, but with specific options to deal with timeouts and retries. With each call persisted in history by default, this is where Temporal shines. Able to keep retrying an activity until it succeeds, even across restarts of the workflow itself for as long as you specify.

public class TableHandler implements TableWorkflow {
    private final TableEventPublisher eventPublisher = Workflow
            .newActivityStub(TableEventPublisher.class, ActivityOptions.newBuilder()
                    .setStartToCloseTimeout(ofSeconds(10))
                    .setRetryOptions(RetryOptions.newBuilder().setMaximumAttempts(3).build())
                    .build());

    private void putBlinds() {
        // uses the activity to create a side effect (in this case publishing an event)
        eventPublisher.blindsPut(new BlindsPut(...));
        // create some delay before dealing the cards
        Workflow.sleep(Duration.ofSeconds(2)); // <-- returns instantly during replay
    }
    ...
}

My minimal activity implementation looks like this for now

@ActivityInterface
public interface TableEventPublisher {
    void blindsPut(BlindsPut blindsPut);
    ...
}
// local-jvm implementation that just puts incoming events on an internal queue
public class QueueTableEventPublisher implements TableEventPublisher {
    private final BlockingDeque<TableEvent> queue = new LinkedBlockingDeque<>();

    @Override
    public void blindsPut(BlindsPut blindsPut) {
        queue.add(blindsPut);
    }

    // ... other specific event methods

    public TableEvent nextEvent() throws InterruptedException {
        return queue.take();
    }
}

Now, just like for the workflow, the activity needs to be registered by a worker. Unlike for workflows, not the implementation class but a specific object needs to be registered. Allowing for easy integration with existing externally managed beans etc. and easy testing!

QueueTableEventPublisher tableEventPublisher = new QueueTableEventPublisher();
worker.registerActivitiesImplementations(tableEventPublisher);

Hooking it all together, with a local dummy-client implementation listening to the published events and sending player actions.

public class PokerServer {
    void main() {
        QueueTableEventPublisher tableEventPublisher = new QueueTableEventPublisher();
        String workflowId = UUID.randomUUID().toString();
        startWorker(tableEventPublisher); // see earlier example
        startWorkflow(workflowId);        // see earlier example
        startClient(tableEventPublisher, workflowId);
    }

    void startClient(QueueTableEventPublisher eventPublisher, String workflowId) {
        WorkflowServiceStubs serviceStubs = WorkflowServiceStubs.newLocalServiceStubs();
        WorkflowClient client = WorkflowClient.newInstance(serviceStubs);
        TableWorkflow tableWorkflow = client.newWorkflowStub(TableWorkflow.class, workflowId);

        while (true) {
            // getting next event
            TableEvent tableEvent = tableEventPublisher.nextEvent();

            // sending a player action
            tableWorkflow.onCheck(new Check(...));
        }
    }
}

Learnings so far

Honestly, the early signals caught me off-guard and I had to double-check if this was indeed intended behavior of the framework, but it is. Choosing not to lose signals in edge-cases over what to me would appear to be a much friendlier default programming model of guaranteed availability of workflow input. Good to learn that they solved this by adding @WorkflowInit which provides exactly that.
Support for checkpointing by Workflow.continueAsNew is straight forward, and it’s quite nice that you can pick any point in the workflow. From history size based to the raising of the blinds or something else that makes more sense to a specific use-case.
The choice to use interface and class for Workflows but an object for Activities seems spot on. Making it a breeze to bring in anything from highly dependency-managed implementations to mocks.

Next up…

Stay tuned for more to come as the code is ready for the next architectural step into multi-table tournaments with a tournament workflow orchestrating its per-table workflows as its ChildWorkflows.

(See here for part 3)

Battle-testing Temporal - Part 1

2026-03-24T21:00:00.000Z

Temporal is gaining traction spearheading a new generation of Workflow tools/frameworks. Namely Durable Execution frameworks. Unlike most Workflow tools/frameworks, Durable Execution frameworks take a code-centric approach (no external models) meant to assist the developer in building complex Workflows (Sagas) that can take anywhere from seconds to months. There is no limit. Promising out-of-the-box support for (re)starting Workflows from exactly where they were (upon failure) based on managed event-sourced state management. Said to support a wide-range of use-cases from multistep financial processes to ML-pipelines in the wild.

From a 1000-feet view it seems like a Durable Execution framework like Temporal could indeed be the first developer-friendly generation of Workflow engines to assist a wide variety of long-running processes.

So join me on this journey and let’s find out if it is truly possible to write production-grade long-running processes in a non-evasive developer-friendly manner by asking my favorite architecture question…

Will it Poker?

In more words, does the architecture withstand all the (non-)functional requirements that stem from supporting a fully-fledged server poker gaming server capable of supporting arbitrary amounts of poker tournaments, each supporting arbitrary amounts of players.

Dealing with:

Transferring of funds from/to player accounts
Coordination between multiple tables (games) part of the same tournament
Server initiated actions/timeouts like dealing cards and default player actions
Stateful behavior that needs to survive all sorts of failures
Usage of randomization to shuffle decks of cards
High traceability & observability requirements
Low-latency fan-out of updates to clients
Clients with incentive to cheat/break the system

Turning it into my go-to proof-of-concept use case.

Disclaimer: this is not "you should build game servers like this", nor a "you should build game servers with Temporal" blog. It is merely blog series about testing if Temporal is up to the task for such complex use-case, highlighting which tradeoffs/benefits it brings.

Skipping the plumping code to set up a workflow, I want to focus in this part 1 on the actual business logic instead.

DIY Approach - what I had to start with

The following pseudocode provides the basic generalized set-up of the code for a turn-based (Poker table) game server. While it has nothing to do with Temporal, it provides a baseline for the code before adding Temporal into the mix. Feel free to laugh at the semi-intentional naive approach ;)

synchronized void runGame(GameState state) {
    while(!state.done) {
        makeProgessIfPossible();
        wait(playerActionTimeout); // Object.wait
        if (!actionTaken) {
            playForCurrentPlayer();
            turnToNextPlayer();
        }
        this.actionTaken = false;
        persistState(state);
    }
}

synchronized void playerAction(Action action) {
    if (legalAction(action)) {
        doAction(action);
        this.actionTaken = true;
        turnToNextPlayer();
        persistState(state);
        notifyAll(); //Object.notifyAll
    }
}

how this patterns works

For those not familiar with plain old Java object locking,this works because the Object.wait(playerActionTimeout) method yields its thread and releases its lock on the gameserver object such that another thread (of the player) may execute the playerAction within the specified timeout. With the Object.notifyAll() call explicitly notifying waiting threads to be woken up out their waiting state. (So that Object.wait never waits longer then needed)

the rough part

In order to properly re-start upon failure, not only does such server code require carefully self-managed persisted state management, it also requires some sort of (distributed) locking mechanism to make sure exactly one server is running/restarting the game at any given point in time.

When bringing observability, error handling, test support, versioning and transactionality into the mix; depending on the exact use-case, building such layer yourself is no small feat. I know this because I built one myself once before. Using the same use-case, as part of another architectural exploration of Message-Driven Moduliths based on Kafka. While great as a feasibility study for such architecture, I would recommend against rolling your own framework for any professional use-case.

Enter - Temporal

So, could Temporal be such framework? Doing the heavy lifting while keeping my own code simple?

And how would vanilla Java code look like when adapted to a Temporal Workflow that supports durable execution?

Directly translated to Temporal

@WorkflowMethod
void runGame(GameState state) {
    while (!state.done) {
        makeProgessIfPossible();
        if (!Workflow.await(playerActionTimeout, () -> this.actionTaken)) {
            playDefaultActionForCurrentPlayer();
            turnToNextPlayer();
        }
    }
}

@SignalMethod
void playerAction(Action action) {
    if (legalAction(action)) {
        doAction(action);
        this.actionTaken = true;
        turnToNextPlayer();
    }
}

The first thing to notice is how little actually had to change to run. The wait/notify has been replaced by the Workflow.await(timeout, conditionFunction) awaiting a specific condition. synchronized is no longer needed because Temporal will never ever have multiple threads active in the same workflow at the same time.

Manually persisting the state is also gone, as Temporal will replay all events (signals) upon restart if needed to re-reach the same internal game state automatically.

In order to update any externally running process, some state change needs to be reported. Temporal provides 4 options for this:

Calling another Workflow’s @SignalMethod (to update another workflow)
Implementing @QueryMethod for fast retrieval of some current state
Pushing state out by means of calling an ActivityInterface that would store/push state to somewhere
New since 2025: Implementing an @UpdateMethod that is able to process data and send back a result, just like the primary workflow method

While the latest one is obviously very powerful, I felt it would introduce a lot of changes to the Workflow as well my envisioned architecture. Which at this point is assumed to look like something this:

Figure 1. Initial Architecture

Specifically sending Actions to the workflow and fanning out results from different components.

Therefore, I opted to stay close to the baseline code and keep sending out state changes as events by using an Activity from anywhere in the code that had a meaningful change to covey to the clients. Not caring too much about latency for now. Properly battle-testing high-frequency use of Activities in the process.

Why the above code-pattern is not correct anymore

The direct translation from the object lock-based approach to a Workflow introduces one small but vital difference in the execution ordering of the code!

In Temporal, Activities are recorded in history first and then scheduled for execution asynchronously. As a result of this, calling an activity (even a void method) triggers a yield of the thread/process that currently executing the workflow method/signal handler that called it. Meaning its flow is potentially interleaved with (parts of) one or more other @SignalMethod/@WorkflowMethod methods before continuing from where it called the activity.

@WorkflowMethod
void runGame(GameState state) {
    someActivity.doSomething(); // activities yield just like Workflow.await...
    // <-- other workflow code may execute in between!
    somethingElse();
    // <-- no other workflow code can run in between
    somethingElse();
}

Coming from a baseline that did not expect any interleaving except on explicit calls to Object.wait (now Workflow.await) calls, this causes subtle issues resulting from out-of-order program flow.

Idiomatic Temporal workflow pattern

Because of the plethora of issues that may arise from executing complex logic from multiple entrypoints, the general advice seems to keep @SignalMethod methods dumb. Instead of fully processing a signal itself, storing any incoming work as a result of a signal in some form of queue. Leaving it up to the sole @WorkflowMethod to actually process. (To me this made quite a bit of sense, which is another reason not to dive into @UpdateMethod based state sharing approach for now.)

When applied to the example above, this translates to:

@WorkflowMethod
void runGame(GameState state) {
    while(!state.done) {
        makeProgessIfPossible();
        Action action;
        if (Workflow.await(playerActionTimeout, () -> this.action != null)) {
            action = this.action;
        } else {
            action = defaultActionForCurrentPlayer();
        }
        doAndClearAction(action); // sets state.action back to null
    }
}

@SignalMethod
void playerAction(Action action) {
    if (this.action == null && legalAction(action)) {
        this.action = action;
    }
}

Not only does this solve the immediate problems with initial naive translated design, it actually deduplicates logic and significantly lowers the cognitive load of dealing with competing sub-processes mutating state and causing side-effects.

You could say, Temporal forced me into a better design.

Note that I didn’t use an actual queue in this example, but instead opted to ignore any additional incoming action before the current one was processed. I mean, you can’t bravely declare CALL then followed by a sneaky fold and expect the fold to count.

Idiomatic Temporal input processing

While not selecting @UpdateMethod to covey state back to clients, it does seem to be a better fit then a @SignalMethod when it comes to processing end-user input. With specific support for light-weight validation and feedback, before recording only valid signals into history. Making it easier to read later.

Revisiting:

@SignalMethod
void playerAction(Action action) {
    if (this.action == null && legalAction(action)) {
        this.action = action;
    }
}

into something like this:

@UpdateValidatorMethod(updateName = "playerAction")
void playerAction(Action action) {
    if (this.action != null) {
        throw new IllegalArgumentException("action already set...");
    }
    if (!legalAction(action)) {
        throw new IllegalArgumentException("illegal action...");
    }
}
@UpdateMethod
void playerAction(Action action) {
    if (this.action != null && legalAction(action)) {
        this.action = action;
    } else {
        log.warn("action {} no longer valid, state: {}", action, state);
    }
}

Note that I didn’t actually remove the validations from the @UpdateMethod, as the execution of these methods can again be interleaved with any workflow processes. This does however add two things:

feedback to clients in the form of exceptions
prevents recording and showing typical bogus actions in the event log

Workflows, determinism and side effects

In a programming model where signals can be replayed to reproduce the state to a certain previous state, two things are problematic:

methods that introduce side effects by making changes outside the workflow,
methods that produce different results each time they are used.

Dealing with side effects

To prevent re-creating any side effects upon replay, all code that triggers side effects must be explicitly run as an Activity. With an Activity also just being code, but behind an interface marked as @ActivityInterface. (Depending on configuration though, the activity code may run remotely on a completely different/dedicated microservice.)

The idea behind this is simple. Upon replay, all events will be replayed but all activities will not. Preventing unwanted duplication of side effects. Instead, any outcome of an activity will be directly shared back to the workflow by the framework, serving it from its persisted history. So if someActivity.doSomething() returned "foo" the first time, it will also return "foo" to the workflow during replay, but its method body will never actually run again.

Note that like most things in a distributed persisted environment Temporal guarantees at least once delivery. Therefore, Workflow, Signal, Update and Activity methods must still deal with being triggered multiple times in edge cases like partial failures, possibly needing idempotency checks to prevent duplicate processing.

Dealing with different results

In order to support methods that produce different results each time the Temporal frameworks Workflow class comes with build-in replacements that record their calls and results in history. Apart from the structural changes in the baseline code, I also had to replace these sort of functions with their Temporal counterparts:

Workflow.randomUUID()

Workflow.newRandom()

Workflow.currentTimeMillis()

Embracing Event-Sourcing

Another adaption from the original baseline code, that was based on persisting its entire state through 1 generic event, is going all-in on the event-sourced nature of Temporal defining small and specific signals and activities. With the framework persisting everything but the actual state itself.

Not only is it more idiomatic EDA, using specific signals and activities to send back events for everything, it helps a lot in leveraging the out-of-the-box observability to gain insights!

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type")
@JsonSubTypes({
        @Type(value = PlayerFolded.class, name = "PlayerFolded"),
        @Type(value = PlayerBetted.class, name = "PlayerBetted"),
        @Type(value = PlayerChecked.class, name = "PlayerChecked"),
        @Type(value = PlayerRaised.class, name = "PlayerRaised"),
        ...
})
sealed public interface TableEvent permits
        PlayerFolded, PlayerBetted, PlayerChecked, PlayerRaised, ... {
    UUID tournamentId();
    int tableId();
    long eventId();
    Date occurredAt();
}

With each concrete record containing at least these four fields, but in addition anything else specific to its event.

All used as separate activities and update methods:

@ActivityInterface
public interface TableEventPublisher {
    void playerFolded(PlayerFolded playerFolded);
    void playerChecked(PlayerChecked playerChecked);
    void playerBetted(PlayerBetted playerBetted);
    ...
}

@WorkflowInterface
public interface TableWorkflow {
    @UpdateMethod void onFold(Fold fold);
    @UpdateMethod void onCheck(Check check);
    @UpdateMethod void onBet(Bet bet);
    ...
    @UpdateValidatorMethod(updateName = "onFold") void validateFold(Fold fold);
    @UpdateValidatorMethod(updateName = "onCheck") void validateCheck(Check check);
    @UpdateValidatorMethod(updateName = "onBet") void validateBet(Bet bet);
    ...
}

When running the actual game, looking at the build-in dashboard it creates a nice overview updated real-time as the game goes on. (Filtering on Activities for brevity)

Figure 2. Temporal Event History Dashboard (time on X-axis →)

Learnings so far

Development of a long-running stateful process feels quite natural, without any particular invasive behavior or altering the general devx of typical software development. Which is quite unlike other workflow frameworks that tent to be based on (BPMN-)model-first based approaches.
Signal handlers must be implemented in a very specific way such that they queue their signal to not introduce subtle bugs (more on this in next part). With the framework not shielding the user from implementing code that seemingly works but isn’t truly correct. I guess this is the exact other edge of the sword when it comes to full freedom to model the workflow directly in code (wrongly).
Overall Temporal sets up a nice environment for workflows to run in, completely restartable, observable and deterministic based on event-sourcing.
Choosing how to share the workflow state to clients seems to have a high impact on the overall code/flow and should not be considered an afterthought.

Next up…

Stay tuned for getting down and dirty with hardening the workflow for recreation from state, continuation & communication.

(See here for part 2)

OAuth 2.0 and OIDC Explained with UML

2026-03-04T06:30:00.000Z

The purpose of Open Authorization 2.0 (OAuth 2.0) is to give an application (the "Client") limited access to your data at another service (the "Resource Server"), without having to give your password to that application. When OIDC is added Single Sign-On (SSO) is supported as well. The flow of these protocols can nicely be shown in a UML Sequence Diagram.

OAuth 2.0 with optional OIDC

Registration

Before running the Client app as depicted in de diagram below, one must register its client_id, client_secret, and redirect URIs at the Authorization Server.

When JSON Web Key Set (JWKS) is used the Resource Server uses the public key to decrypt the JWT (JSON Web Token), which has been encrypted by the Authorization Server with its private key. Else if a symmetric key is used to encrypt the token that must have been shared by the Authorization Server with the Resourcse Server first.

The Flow

OAuth 2.0 deals with authorizations (aka. permissions). It is meant for getting the authorizations of a user (the Resource Owner) to access resources at an external Resource Server from an external Authorization Server. With 'external' meaning the Resource Server is not part of the organisation of the Client application. The authorizations are packed in an Access Token and an accompanying Refresh Token. The latter, to refresh the Access Token when it expires.

Optionally OpenID Connect (OIDC) is for authentications. It is an extension on OAuth and is used to acquire some user specific data from the Authorization Server. That data is provided via an ID Token, and can be used by the Client to verify the name, e-mail address, etc. provided by the user.

Here is an example of the roles:

Role	Example
Resource Owner	You (the user)
Client	Slack
Authorization Server	Google Accounts / OAuth
Resource Server	Google Calendar API

Switching on OIDC can be done by adding the value openid to the scope parameter (see diagram below). For example like this:

OAuth 2.0 only:

scope=https://www.googleapis.com/auth/calendar.readonly

OAuth 2.0 with OIDC:

scope=openid profile email https://www.googleapis.com/auth/calendar.readonly

Description:

OIDC scopes:

openid: also use OIDC.
profile: request standard profile info of user, like, name, photo, etc.
email: also request the user’s email address.

OAuth 2.0 scope example:

https://www.googleapis.com/auth/calendar.readonly: request readonly permission for Google Calendar API.

The scopes profile and email are sometimes also added when using OAuth 2.0 only. In that case this is sometimes interpreted by the Authorization Server as an additional request to access some user data endpoint. The Client can then request user data with an additional call to that endpoint using the Access Token.

Depicted below is the flow of an OAuth 2.0 process with optional OIDC.

Figure 1. OAuth 2.0 and OIDC Sequence Diagram

(This image was generated from these sources, see also PlantUML in AsciiDoc with Maven.)

Flyway the Right Way

2026-03-03T06:30:00.000Z

Sometimes when you upgrade your application the new version does not work correctly, and you need to downgrade. When you are unlucky you did some changes in your database that cannot be undone. In that case you need to restore the database from a backup, which is usually quite cumbersome and time-consuming. How nice would it be if you could just run an undo script which is much more light weight. This blog describes how you can do that using Flyway.

Steps to follow

Create a downgrade script for every upgrade script.
Make both scripts idempotent, by using IF EXISTS constructs. This makes your scripts more robust and testable.
Do not add irreversible changes to the upgrade script. So do not use statements like delete or drop. Instead, use rename, and do the actual deletes and drops some version later.

Here is an example for MariaDB:

V1.7__rename_table_city_and_person_columns.sql:

ALTER TABLE IF EXISTS city RENAME TO deprecated_city;

ALTER TABLE
    person RENAME COLUMN IF EXISTS name TO deprecated_name,
    person ADD COLUMN IF NOT EXISTS first_name VARCHAR(255),
    person ADD COLUMN IF NOT EXISTS last_name VARCHAR(255);

UPDATE person SET first_name = deprecated_name;

U1.7__rename_table_city_and_person_columns.sql:

ALTER TABLE IF EXISTS deprecated_city RENAME TO city;

ALTER TABLE person RENAME COLUMN IF EXISTS deprecated_name TO name;
--  No need to drop added columns, they are harmless.

And then a few releases later:

V1.11__drop_deprecated_table_and_column.sql:

DROP TABLE IF EXISTS deprecated_city;

ALTER TABLE person DROP COLUMN IF EXISTS deprecated_name;

And now there is no undo script, because this cannot be undone. However, since this is a few releases later you should have noticed any issues with the missing (because they were renamed) table and column in earlier releases already.

NB When you run the undo script manually, you will have to update the flyway history table manually as well. See also Flyway in the Flyway in the command-line.

Nushell Niceties: Checking If Value Is In List Or String Or Key In Record

2026-03-03T04:46:18.000Z

Nushell has the in operator to check if a value is an element of list. With the same in operator you can check if a string is a substring of another string. And finally you can use the in operator to check if a key is in a record. When you use the operator the value you want to check is defined before the operator and the list, other string or record is defined after the operator.
The not-in operator is the opposite of the in operator and checks if a value is not in list or other string or key in a record.
It is also possible to use the has and not-has operators to do the same checks, but the value you want to check is set after the operator. The list, other string or record is set before the operator.

In the following example the operators are used with lists:

use std/assert

# Using in operator to check if a value is in a list.
assert (1 in [1 2 3 4])
assert ('Nushell' in ['Nushell' 'rocks'])

# Using not-in operator to check if a value is not in a list.
assert (1 not-in [2 3 4])
assert ('nushell' not-in ['Nushell' 'rocks'])


# Using has operator to check if a value is in a list.
assert ([1 2 3 4] has 1)
assert (['Nushell' 'rocks'] has 'Nushell')

# Using not-has operator to check if a value is not in a list.
assert ([1 2 3 4] not-has 5)
assert (['Nushell' 'rocks'] not-has 'nushell')

In the following example the operators are used with strings:

use std/assert

# Using in operator to check if a value is in a string.
assert ('Nushell' in 'Nushell rocks!')

# Using not-in operator to check if a value is not in a string.
assert ('awesome' not-in 'Nushell rocks!')


# Using has operator to check if a value is in a string.
assert ('Nushell rocks' has 'Nushell')

# Using not-has operator to check if a value is not in a string.
assert ('Nushell rocks' not-has 'awesome')

In the following example the operators are used with records:

use std/assert

# Using in operator to check if a key is in a record.
assert ('name' in {name: 'mrhaki' location: 'Tilburg'})

# Using not-in operator to check if a key is not in a record.
assert ('age' not-in {name: 'mrhaki' location: 'Tilburg'})


# Using has operator to check if a key is in a record.
assert ({name: 'mrhaki' location: 'Tilburg'} has name)

# Using not-has operator to check if a key is not in a record.
assert ({name: 'mrhaki' location: 'Tilburg'} not-has age)

Written with Nushell 0.110.0.

Original post

Kotlin protip: indexed access operator overloading with multiple indices

2026-02-25T07:00:00.000Z

Operator overloading is one of Kotlin’s most beloved features. It lets you give familiar syntax to custom types, and you’re probably already using it without even noticing it. Take the Map interface, for example: the indexed access operator ([]) is used to read and write entries:

val m = mutableMapOf<Int, String>()
m[1] = "one"     // m.put(1, "one")
val value = m[1] // m.get(1)

The same syntax works for arrays, lists, and any type that declares an operator fun get or operator fun set. Did you know that you can overload the indexed access operator with multiple indices?

Example: A two-dimensional grid that stores its data in a one-dimensional Array

A common scenario where multi-index access is handy is a two-dimensional grid. Below is a Grid class that keeps its state in a single Array and exposes a natural grid[x, y] syntax for both reading and writing.

class Grid(val width: Int, val height: Int) {
    /** Create a one-dimensional array, initially filled with all zeroes */
    private val data = Array(width * height) { 0 }

    /** Convert (x, y) to the underlying one-dimensional index */
    private fun index(x: Int, y: Int): Int = y * width + x

    /** Read the element at (x, y), or return `null` for non-existing coordinates */
    operator fun get(x: Int, y: Int): Int? = data.getOrNull(index(x, y))

    /** Write a new value at (x, y) */
    operator fun set(x: Int, y: Int, value: Int) {
        require(x in 0..<grid.width && y in 0..<grid.height)
        data[index(x, y)] = value
    }
}

Using the Grid

val grid = Grid(width = 3, height = 2) // 3 columns × 2 rows

grid[1, 0] = 42     // Set cell (1, 0) to value 42
println(grid[1, 0]) // → 42

// Print the entire grid
for (y in 0..<grid.height) {
    for (x in 0..<grid.width) {
        print("${grid[x, y]} ")
    }
    println()
}

With the operator fun get and operator fun set signatures, the compiler simply translates grid[x, y] int a call to grid.get(x, y). Similarly, grid[x, y] = v translates to grid.set(x, y, v). Multiple indices are just multiple parameters.

In this example, I am using Int parameters only, but this can be anything. For example, it is perfectly valid to write operator fun get(x: String, y: Int): Double { … }, and call the function like this: grid["hello", 5]. The corresponding set function would be: operator fun set(x: String, y: Int, value: Double) { … }

Why overload with multiple indices?

Using a multi-index signature makes the grid’s API feel more natural: grid[x, y] reads like "the cell at (x, y)", while keeping the underlying one-dimensional array hidden from callers, so they don’t need to worry about row-major ordering. This encapsulation also gives you the flexibility to swap out the storage strategy later without touching any client code.

Summary

Kotlin’s indexed access operator can be overloaded for any number of indices (e.g. a 3D grid with an x, y, and z coordinate). A 2D grid backed by a 1D array is a perfect example: just declare operator fun get(x, y) and operator fun set(x, y, value) and you get a clean, idiomatic API.

Shoutout to Alexander Chatzizacharias for reminding me of this awesome Kotlin feature.

Bonus: From Java to Kotlin – Part XII: Sealed Classes vs Enums / Polymorphism

2026-02-24T08:00:00.000Z

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 12: In this post, we explore how to model a finite set of types in Java — the “old way” with enums or class hierarchies, the “new way” with Java SE 17+ sealed classes — and then see how Kotlin handles them elegantly with sealed classes.

The problem

Suppose you have a concept with a finite number of types, like a payment status:

Pending
Completed
Failed

You want to be able to:

Represent the different types
Optionally store extra data per type
Handle each type safely and exhaustively

In other words: you want your program to know whether your money has arrived, is fashionably late, or vanished into the void — all without having to play detective in instanceof checks.

Java 'the old way': Enums or Class Hierarchies

Using Enums

public enum PaymentStatus {
    PENDING,
    COMPLETED,
    FAILED
}

Usage:

PaymentStatus status = PaymentStatus.PENDING;

switch (status) {
  case PENDING:
    System.out.println("Pending...");
    break;
  case COMPLETED:
    System.out.println("Completed!");
    break;
  case FAILED:
    System.out.println("Failed!");
    break;
}

✅ Works for simple states

❌ Cannot store per-case extra data easily

❌ Cannot attach behavior without extra boilerplate

Using Class Hierarchies

abstract class PaymentStatus {}

class Pending extends PaymentStatus {}
class Completed extends PaymentStatus {
    private final LocalDateTime completedAt;
    Completed(LocalDateTime completedAt) { this.completedAt = completedAt; }
}
class Failed extends PaymentStatus {
    private final String reason;
    Failed(String reason) { this.reason = reason; }
}

Usage:

PaymentStatus status = new Completed(LocalDateTime.now());

if (status instanceof Completed c) {
  System.out.println("Completed at " + c.completedAt);
} else if (status instanceof Failed f) {
  System.out.println("Failed because " + f.reason);
}

✅ Can store extra data

❌ Boilerplate + instanceof checks

❌ No compile-time guarantee that all cases are handled

Java 'the new way': Sealed Classes with Exhaustive Switch (Java 21+)

Java SE 17 introduced sealed classes (JEP 409), allowing a class or interface to define which subtypes are permitted. With Java 21, enhanced switch statements and pattern matching make it possible for the compiler to enforce exhaustive handling of all sealed subtypes — similar to Kotlin’s when.

public abstract sealed class PaymentStatus
  permits Pending, Completed, Failed { }

public final class Pending extends PaymentStatus { }

public final class Completed extends PaymentStatus {
  private final LocalDateTime completedAt;
  public Completed(LocalDateTime completedAt) { this.completedAt = completedAt; }
}

public final class Failed extends PaymentStatus {
  private final String reason;
  public Failed(String reason) { this.reason = reason; }
}

Using an exhaustive switch:

PaymentStatus status = new Completed(LocalDateTime.now());

switch (status) {
  case Pending p -> System.out.println("Pending...");
  case Completed c -> System.out.println("Completed at " + c.completedAt);
  case Failed f -> System.out.println("Failed because " + f.reason);
}

✅ The compiler ensures that all subtypes of PaymentStatus are handled

✅ No default branch needed

✅ Safe and concise, similar to Kotlin’s when

Note: The older switch syntax without pattern matching still requires a default and does not enforce exhaustiveness.

The Kotlin way: Sealed Classes

Kotlin’s sealed classes work similarly to Java’s sealed classes in that the compiler knows all possible subtypes. However, unlike Java, you do not need to explicitly list the permitted subclasses — all subclasses must be declared in the same file. This automatically keeps the class hierarchy "closed" and allows the compiler to enforce exhaustive when expressions.

Finite set of subtypes
Optional data per subtype
Exhaustive when expressions
Concise syntax with minimal boilerplate

sealed class PaymentStatus

data object Pending : PaymentStatus()
data class Completed(val completedAt: LocalDateTime) : PaymentStatus()
data class Failed(val reason: String) : PaymentStatus()

Usage:

val status: PaymentStatus = Completed(LocalDateTime.now())

when (status) {
  is Pending -> println("Pending...")
  is Completed -> println("Completed at ${status.completedAt}")
  is Failed -> println("Failed because ${status.reason}")
}

✅ Compiler ensures all cases are handled

✅ No instanceof boilerplate

✅ Each subtype can hold its own data

Polymorphism without `when`

Sealed classes can also encapsulate behavior:

sealed class PaymentStatus {
  abstract fun message(): String
}

data object Pending : PaymentStatus() {
  override fun message() = "Pending..."
}

data class Completed(val completedAt: LocalDateTime) : PaymentStatus() {
  override fun message() = "Completed at $completedAt"
}

data class Failed(val reason: String) : PaymentStatus() {
  override fun message() = "Failed because $reason"
}

val status: PaymentStatus = Completed(LocalDateTime.now())
println(status.message())

✅ Cleaner polymorphic code

✅ Each subtype contains its own behavior

Short catch-up: What is Polymorphism?

Polymorphism is the ability of a type to take multiple forms. In practice, it means you can write code that works on a general type (like a superclass or interface) but behaves differently depending on the specific subtype at runtime.

For example, with a sealed PaymentStatus, you can handle Pending, Completed, or Failed in the same switch or when block, but each subtype can have its own data and behavior.

Enum vs Sealed Class vs Data Class

Feature	Enum	Java Sealed (JDK 21+)	Kotlin Sealed
Finite set of types	✅	✅	✅
Extra data per type	❌ (tricky)	✅	✅
Custom behavior per type	❌	✅ (requires methods / boilerplate)	✅ (clean)
Exhaustive checks	✅ (switch)	✅ (with enhanced switch / pattern matching)	✅ (compiler enforced)
Boilerplate	Low	Medium	Low

Rule of thumb

Enum → simple flags
Data class → flat objects
Sealed class → hierarchies with data and behavior

Takeaway

Java “old way”: enums or class hierarchies → works, but often verbose
Java “new way”: sealed classes → controlled hierarchies, safer, closer to Kotlin
Kotlin sealed classes → expressive, concise, compile-time safe, and polymorphic

Tip: In Kotlin, you can also use a sealed interface instead of a sealed class. This is useful if some subtypes need to inherit from another class (since Kotlin allows only single class inheritance). The compiler still enforces exhaustive when checks.

sealed interface PaymentStatus

data object Pending : PaymentStatus
data class Completed(val completedAt: LocalDateTime) : PaymentStatus
data class Failed(val reason: String) : PaymentStatus

✅ More flexibility without losing the benefits of sealed classes.

✅ Still fully compile-time safe with exhaustive when expressions.

Rule of thumb

Use sealed class by default if no other superclass is needed.
Use sealed interface when you want extra flexibility in the type hierarchy.

Sources / Links

From Java to Kotlin – Part XI: The Builder Pattern vs Type-safe Builders / DSL

2026-02-23T08:00:00.000Z

Case 11: You want to construct an object.

With many parameters. Some optional. Readable. Preferably without a constructor that looks like a password.

The problem

You have a class with multiple fields.

Some required. Some optional.

And you want:

readability
immutability
no telescoping constructors

In Java, this usually means one thing.

The Builder pattern.

The Java way

The classic version:

public class User {
  private final String name;
  private final String email;
  private final int age;

  private User(Builder builder) {
    this.name = builder.name;
    this.email = builder.email;
    this.age = builder.age;
  }

  public static class Builder {
    private String name;
    private String email;
    private int age = -1;

    public Builder name(String name) {
      this.name = name;
      return this;
    }

    public Builder email(String email) {
      this.email = email;
      return this;
    }

    public Builder age(int age) {
      this.age = age;
      return this;
    }

    public User build() {
      return new User(this);
    }
  }
}

Usage:

User user = new User.Builder()
    .name("John")
    .email("john@doe.com")
    .age(42)
    .build();

It works.

But it’s a lot of code for: “Create an object.”

So we reach for Lombok:

@Builder
public class User {
  private String name;
  private String email;
  private int age;
}

Better.

But still:

User user = User.builder()
    .name("John")
    .email("john@doe.com")
    .age(42)
    .build();

We are solving a language limitation with a pattern. And then solving the pattern with an annotation processor.

The Kotlin way

In Kotlin, the primary constructor already gives you most of this:

data class User(
  val name: String,
  val email: String,
  val active: Boolean = true
)

Usage:

val user = User(
  name = "John",
  email = "john@doe.com"
)

That’s it.

Named arguments
Default values
Immutability
No builder required

And it stays readable — even with many parameters.

But what if the object becomes complex?

This is where Kotlin does something Java simply cannot do:

Type-safe builders, often used to create a small DSL.

A quick note: what is a DSL?

DSL stands for Domain-Specific Language.

That sounds heavier than it is.

It simply means: A small, readable language focused on one specific task.

Not a new programming language — just a more expressive way to use Kotlin.

For example:

html {
  body {
    h1("Hello")
  }
}

or:

dependencies {
  implementation("org.jetbrains.kotlin:kotlin-stdlib")
}

You are not calling constructors.

You are describing a structure.

That is the key difference.

A builder chains method calls. A DSL models a domain.

A Kotlin type-safe builder

val user = user {
  name = "John"
  email = "john@doe.com"
  age = 42
}

With:

fun user(block: UserBuilder.() -> Unit): User =
  UserBuilder().apply(block).build()

This gives you:

a scoped configuration block
compile-time safety
no partially built objects leaking out

And the call site reads like configuration instead of construction.

ps. An example of the UserBuilder is below here in the 'Validating while building' part.

Why this matters

The Java builder pattern is:

ceremony for optional parameters
ceremony for readability
ceremony for immutability

Kotlin removes the need for that ceremony.

And when you do need structure for complex hierarchies, a DSL gives you something the classic builder never could:

Structure in the call site.

Not just chaining.

Takeaway

In Java:

You build because constructors don’t scale.

In Kotlin:

You use the constructor — and only build when you’re actually building something.

A builder constructs objects.

A DSL describes them.

Coming from Lombok?

Your Kotlin replacement is usually:

a data class
default values
named arguments

Not another builder.

And your code gets smaller. And clearer. By default.

When not to use a DSL

A DSL is not a default replacement for a constructor or a data class.

If you only have:

a flat object
a handful of parameters
no nested structure

then a regular constructor with named arguments is clearer and simpler.

val user = User(
  name = "John",
  email = "john@doe.com"
)

No builder. No DSL. No extra types.

Just the model.

A DSL starts to make sense when:

you are building a hierarchy
the structure matters
the block improves readability
you would otherwise end up with deeply nested constructors or long method chains
you want easy validation within the builder

Validating while building

A nice bonus of a Kotlin DSL builder is that you can validate your object state before it’s constructed. For example, you can enforce rules in the builder itself:

class UserBuilder {
  var name: String = ""
  var email: String = ""
  var age: Int = -1
  var role: String? = null

  fun build(): User {
    require(name.isNotBlank()) { "Name must not be blank" }
    require(email.contains("@")) { "Email must be valid" }
    require(age >= 0) { "Age must be non-negative" }
    if (role != null) require(age >= 18) { "Users with a role must be at least 18" }
    return User(name, email, age)
  }
}

Usage:

val user = user {
  name = "John"
  email = "john@doe.com"
  age = 42
  role = "admin"
}

This demonstrates how type-safe builders can enforce both simple and dependent validations automatically at build time, keeping your objects consistent without extra boilerplate — something that would be more cumbersome with Java builders.

Note: This can be done in Java as well, it’s an advantage of the builder-pattern versus using the constructor.

Typical good fits are:

HTML / UI trees
routing definitions
test data builders
complex configuration objects

Using a DSL for a simple data holder is not expressive.

It’s noise.

And unlike in Java, in Kotlin you don’t need a pattern to compensate for the language.

So don’t.

Sources / Links

Digital Sovereignty, A Dutch company's dilemma in the age of US hyperscalers

2026-02-22T06:56:00.000Z

If you run into a wall, don’t turn around and give up. Figure out how to climb it, go through it, or work around it." — Michael Jordan

The grip tightens

Dutch companies find themselves in an uncomfortable position. Their data flows through AWS, Azure, or Google Cloud. Their productivity tools are Microsoft 365 or Google Workspace. Their AI capabilities depend on OpenAI or Anthropic. The convenience is undeniable, but so is the dependency.

Digital sovereignty isn’t just a buzzword, it’s about control. Control over your data, your operations, and ultimately, your business continuity when geopolitical winds shift.

The real considerations

Legal and regulatory risk:

The CLOUD Act gives US authorities access to data held by US companies, regardless of where it’s stored. For Dutch companies it can create a legal minefield to handle sensitive data, like healthcare records, financial information or government contracts. GDPR compliance becomes complex when your cloud provider can be compelled to hand over EU citizen data to US authorities without being allowed to tell you it happened. Which raises the question: can you even be compliant when a non-compliant government can compel your data?

Operational dependency:

What happens when AWS has an outage in eu-west-1? Your business stops. Not because your code broke, but because someone else’s infrastructure did. What if Microsoft changes pricing by 30%? You pay it, because migrating is harder than absorbing the increase. What if your hyperscaler exits a service you depend on, or geopolitical tensions lead to service restrictions? You scramble.

You’re not just buying infrastructure, you are outsourcing strategic decision making.

Economic sovereignty:

Every euro spent on US hyperscalers leaves the European economy. At scale, that’s billions flowing to Seattle and Silicon Valley annually. The Netherlands has strong tech capabilities, but the ecosystem struggles to grow when every default architecture decision routes money and talent away from it. The companies you’re funding with your cloud bill are also your competitors in the war for engineering talent.

Innovation lock-in:

Hyperscaler-specific services like Lambda, Azure Functions, or BigQuery create deep technical debt that’s easy to miss until it’s too late. Your developers learn to think in AWS primitives, not distributed systems. Your architecture encodes hyperscaler assumptions at every layer. By the time you want to leave, you’re not migrating infrastructure, you’re rewriting your product. Switching costs don’t just become prohibitive, they become existential.

Your options

The status quo

Let’s be honest, for many companies, sticking with AWS, Azure or Google Cloud remains the pragmatic choice. The hyperscalers didn’t become dominant by accident. They offer unmatched scale and reliability that most companies can’t replicate and a feature velocity that keeps you competitive. The question is: are you Netflix and do you need it? Most companies aren’t, and most are running infrastructure that’s wildly overprovisioned for their actual needs.

If you’re a startup trying to move fast, or you operate globally and need infrastructure on every continent, or frankly, if you lack the internal expertise to run infrastructure yourself, the hyperscalers make sense. The key is doing it consciously, not by default.

Bert Hubert, Dutch technologist and founder of PowerDNS, makes this point sharply in his Europe’s executives need to skill up to solve our total US cloud dependency: leadership has been indoctrinated that nothing other than US clouds is possible, while the IT people who ran perfectly fine local infrastructure haven’t gone anywhere. Their skills are still around.

The smart play here isn’t pretending sovereignty doesn’t matter. It’s mitigation. Implement strict data residency controls. Negotiate contractual protections where possible. And critically, maintain architectural portability and avoid the deepest lock-in traps even if you’re staying put. Think of it as keeping your options open for a future you can’t predict.

The European alternative

There’s a growing constellation of European cloud providers that deserve serious consideration. OVHcloud in France, Hetzner in Germany, TransIP and Cyso here in the Netherlands, and emerging sovereign cloud initiatives like Gaia-X that promise GDPR-native infrastructure from the ground up. For a comprehensive overview of European alternatives across many categories, check out European Alternatives.

These providers shine when your data is genuinely sensitive and your scale doesn’t demand a global footprint. You’d be surprised how far well-architected infrastructure on European providers will take you. They’re often 30-50% cheaper than hyperscalers, which isn’t trivial when cloud bills run into six or seven figures. And there’s something to be said for supporting European digital infrastructure, every company that chooses European clouds makes the ecosystem stronger.

But let’s not romanticize it. European providers offer fewer managed services, which means more operational burden on your teams. Their global footprint is smaller, so if you need low latency in Singapore, you’re out of luck. Their AI and ML offerings lag behind what you get from AWS SageMaker or Google Vertex AI. And the talent pool is smaller, finding engineers who know OVHcloud is harder than finding AWS experts.

The European cloud path works best when sovereignty is a genuine requirement, not just a nice-to-have, and when you have the engineering maturity to handle more infrastructure yourself.

One more thing. Moving from one cloud provider to another doesn’t eliminate lock-in risk, it just shifts it. If you’re migrating to a European provider to escape hyperscaler dependency, build portability into your architecture from day one. Use standard technologies, containerize your workloads, avoid provider-specific services where possible. You need an exit strategy even for your sovereignty solution. The goal isn’t to trade one lock-in for another, it’s to maintain the flexibility to move if circumstances change.

The hybrid approach

What if you didn’t have to choose? The hybrid sovereignty model says: put different workloads where they make the most sense. Keep your sensitive customer data and core systems on European infrastructure. Run your commodity workloads, development environments, testing, public-facing content on hyperscalers where they’re convenient.

This is the sophisticated choice, but it requires sophistication to execute. You need clear policies about what goes where. You need the operational maturity to manage multiple cloud providers without drowning in complexity. Kubernetes becomes your abstraction layer, giving you portability across environments.

The hybrid approach works beautifully when you have complex regulatory requirements that demand sovereignty for some data or workloads but not all. Financial services companies often land here, customer transactions on European infrastructure, their marketing website on a global CDN. Healthcare companies put patient records in sovereign clouds but run their research analytics wherever the compute is cheapest.

The risk is ending up with the worst of both worlds, the complexity of multi-cloud without the benefits. You need strong engineering leadership and clear architectural principles to make this work. And be honest with yourself: hybrid can become a way to avoid making a real choice, letting the problem linger rather than solving it.

The private cloud

On-premises infrastructure and private clouds sound like a relic from 2010, but they’re alive and well in certain sectors. Financial services, healthcare, and government contractors often find that regulatory requirements simply mandate it. If you already have data center investments and your workloads are stable and predictable, a private cloud can make economic sense.

The modern approach doesn’t mean buying servers and racking them yourself. It means OpenStack or Kubernetes-based private clouds in Dutch data centers like Equinix or NorthC. Using tools like Terraform and Ansible, you get the same self-service agility as AWS, you can spin up infrastructure in minutes instead of weeks, but everything runs on hardware you control.

This path requires deep infrastructure expertise. You need 24/7 operations capability. You need to match hyperscaler SLAs with your own team. It’s not for everyone, but for organizations with the right profile, large enterprises, regulated industries, governments it’s a viable sovereignty strategy that also happens to offer complete control.

How to prioritize

Start with data classification

Not all data is created equal. Map everything you have by sensitivity. If you’re GDPR-compliant, you’ve already done this. Your records of processing activities are exactly that map. Your critical sovereign data, customer PII, health records, financial transactions, anything touching state secrets, that’s your first priority. Then, sensitive business data, like proprietary algorithms and strategic plans. Finally, commodity data that doesn’t matter much, public content, anonymized analytics, development environments.

The critical sovereign data needs to leave hyperscalers first, or at minimum needs the strongest protections. Everything else can wait.

Assess your regulatory exposure

Some companies face existential regulatory risk, others face minor compliance headaches. If you’re a government supplier, you’re high priority. Governments are asking harder questions about where their data lives. Healthcare and financial services companies handling regulated data are high priority. Critical infrastructure operators are high priority. If you process any personal data, you’re also high priority. The CLOUD Act means you may simply be unable to meet your GDPR obligations while staying on US hyperscalers.

Audit your technical dependencies

How deep is your lock-in? If you’re using only IaaS, virtual machines, block storage, networking, you can migrate relatively easily. Managed databases add moderate complexity but are still portable. Serverless and proprietary services like AWS Lambda or Azure Cognitive Services create high complexity. Deep AI/ML platform integration creates very high complexity.

Start your sovereignty journey with the loosely coupled workloads. Don’t begin by trying to migrate your most hyperscaler-dependent application, you’ll fail and give up. Start with something achievable.

Run the numbers

Build a real cost-benefit analysis. Calculate your current hyperscaler spend. Estimate migration costs honestly, engineering time, tooling, risk, opportunity cost. Project ongoing operational costs of alternatives. Factor in risk costs like potential regulatory fines or business disruption. Don’t forget strategic value, customer trust, competitive advantage, negotiating leverage.

Build a three-year total cost of ownership model. Sometimes sovereignty is more expensive. Sometimes it’s cheaper. Basecamp’s cloud exit is a useful reality check: they saved $3.2M annually by moving off AWS and Google Cloud onto their own hardware. At least you’ll know.

Know your capabilities

Be brutally honest about your team’s capabilities. Do you have infrastructure engineering talent who can run production systems? Can you operate Kubernetes reliably? Do you have 24/7 operations capability, or are you a 9-to-5 shop? Can you realistically match hyperscaler SLAs, and do you need to?

If your capabilities are low, don’t try to build a private cloud. Start with managed European providers who handle the operational burden. You don’t need to suffer for sovereignty.

The Dutch advantage

The Netherlands is uniquely positioned to lead on digital sovereignty. We have great digital infrastructure. We have a progressive data protection culture that values privacy. We have the technical talent pool to execute sophisticated strategies. We have government support for digital sovereignty initiatives. And our geographic position makes us a natural European data gateway.

Dutch companies can demonstrate that sovereignty and innovation aren’t mutually exclusive. We can build the playbook others follow.

Conclusion: Sovereignty as strategy

Digital sovereignty isn’t about nationalism or technophobia. It’s about strategic autonomy in an uncertain world.

The Netherlands has a peculiar talent. We’re a small country that consistently punches above our weight at the Winter Olympics, dominating speed skating against nations ten times our size. We do this not through brute force, but through focus, technique, and relentless optimization of what we’re good at.

Digital sovereignty requires the same mindset. We can’t outspend AWS. We can’t match Google’s global infrastructure footprint. But we can be strategic, focused, and smart about where we compete and where we collaborate.

For Dutch companies, the question isn’t "hyperscaler or not?" but "which workloads, under what conditions, with what safeguards?"

Start with your most sensitive data. Build portable architectures. Support European alternatives where viable. Maintain pragmatism, sometimes AWS is the right answer.

Make it a conscious choice, not a default. Your future flexibility depends on decisions you make today.

The grip of hyperscalers is strong, but not unbreakable. Like our speed skaters finding the perfect line on the ice, it requires intention, investment, and a clear-eyed view of what sovereignty means for your specific business.

We’ve proven we can compete on the world stage when we focus on our strengths. Digital sovereignty is our next race to win.

Running COBOL in IntelliJ

2026-02-21T06:00:00.000Z

Within the JVM community, once in a while somebody jokes about getting old and therefore needing to start learning COBOL. Usually, someone responds that there are indeed some “precious older people” who wrote COBOL, or dare I say it, still write COBOL today. For me, COBOL has always sounded like a relic of the past. Something you read about, not something you seriously consider learning. But lately, I have been hearing rumours about companies starting to recruit new employees specifically to fill COBOL vacancies. That triggered me hard enough to start wondering. Can I actually run COBOL on my own laptop today, and if so, can I have a reasonably nice developer experience while doing so?

So I needed to tackle two things: installing a compiler to actually run COBOL code, and finding an IDE that would give me a decent developer experience. For me, that effectively meant using IntelliJ. It is the IDE I use every day, and thus I am very much familiar with it. Ideally, that meant finding a COBOL plugin that would integrate reasonably well into my existing setup.

Luckily, finding a plugin took about five seconds. The Zowe™ COBOL Language Support plugin looked like exactly what I needed, so I installed it. Next, I let ChatGPT generate a classic hello world example for me, because I definitely do not know any COBOL yet:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO.

       PROCEDURE DIVISION.
           DISPLAY "Hello, world".
           STOP RUN.

And then I immediately hit a wall. There was no run button in sight. After a bit of investigation, it turned out that the plugin only provides TextMate-based syntax highlighting and LSP support. That means decent code coloring and some basic validation, but no support for compiling or actually running COBOL code.

So I thought of something else. What if I simply installed a compiler myself and used IntelliJ’s "Run Configuration" to run a shell script that compiles and runs the currently opened COBOL file? That way, it would still almost feel like native IntelliJ support. Installing a COBOL compiler on macOS turned out to be trivial. A single brew install gnucobol was enough to get GNU COBOL up and running. The only thing missing was the script itself, which could easily be generated by AI.

#!/bin/zsh
set -e

error() {
  echo "\033[31m$1\033[0m"
}

if [ -z "$1" ]; then
  error "No file provided."
  exit 1
fi

SRC="$1"
EXT="${SRC##*.}"

if [[ "$EXT" != "cob" && "$EXT" != "cbl" ]]; then
  error "This is not a COBOL file. Only .cob or .cbl extensions are supported!"
  exit 1
fi

OUT="$(basename "$SRC" .$EXT)"

cobc -x "$SRC" -o "$OUT"
./"$OUT"

To make this work, I needed to figure out a way to select the current opened file. After a bit of research, I discovered that IntelliJ provides a number of built-in macros, which are essentially variables you can use to define paths, options, and other command-line arguments. The $FilePath$ macro, which resolves to the absolute path of the current file, looked like exactly what I needed. Unfortunately, it turned out to be a dead end! At the time of writing, macros are not supported in Shell Script run configurations, which meant this approach would not work after all.

Bummer. So what now? Luckily, ChatGPT pointed me to IntelliJ’s External Tools feature. This allows you to configure third-party command-line applications and run them directly from IntelliJ. And more importantly, external tools do support macros. That was exactly what I needed! So I wired it up, and configured the tool like this:

Then I had to go to the Tools → External Tools → Run COBOL menu, to run a COBOL file:

/path/to/run.sh /path/to/hello.cob
Hello, world

Process finished with exit code 0

Awesome!

But still, I had to click three times to run the script… So I figured, there’s another thing I can do to make it even more fleshed out. At the top of the IDE sits the toolbar, which is fully customizable. For every action IntelliJ knows about, you can add a custom button to the toolbar. That meant I could create a dedicated action, link it to my “Run COBOL” external tool, and place it right where a run button should be. To make it complete, I used the COBOL rhino as the button icon:

And there you have it: a one-click button I can press anytime I want. With that, my journey to setting up the environment is complete. Now unto the next task, starting to learn the language!

From Java to Kotlin – Part X: Virtual Threads and Coroutines

2026-02-20T08:00:00.000Z

Case 10: You need to do many things at once. Mostly waiting. Sometimes working.

The problem

Modern apps spend a lot of time waiting:

Waiting for a web request
Waiting for a database query
Waiting for a file or message from another system

During I/O waits, threads are blocked, which often leads to low CPU utilization. So the real question is not:

“How fast can we run code?”

but

“How can we wait efficiently?”

The Java way (classic threads)

Java’s old answer: give each task a thread.

Each thread blocks while waiting
The OS schedules threads for you
Works fine for a few tasks

Problems appear with thousands of tasks:

Threads are relatively heavy
Memory usage grows fast
Shared data = easy to make mistakes
Debugging is tricky

Think of threads as people waiting on chairs. Each blocks a chair while they wait — expensive if the room is full.

The Java way (Java 21+): Virtual Threads

Java 21 introduced virtual threads:

Look like threads in code
JVM schedules them efficiently
Blocking a virtual thread doesn’t block an OS thread
You can create thousands with a significantly lower memory overhead

Thread virtualThread = Thread.startVirtualThread(() ->
    System.out.println(message + " from a virtual thread!")
);

virtualThread.join();

Here: the code still “blocks,” but it’s cheap. Your mental model stays the same: threads are doing work.

Virtual threads are perfect if:

Most code is I/O-bound
You have existing blocking APIs
You don’t want to rewrite everything

The Kotlin way: Coroutines

Kotlin asks a different question:

“What does it mean to wait in code?”

Coroutines are not threads. They are small, lightweight units of work that pause and resume:

While waiting, no thread is blocked
Waiting becomes explicit in the API
Cancellation and lifetimes are structured

fun greeting(message: String) = runBlocking {
    println(message)

    launch {
        println("$message from a coroutine!")
    }
}

runBlocking = create a coroutine scope from a blocking (non-coroutine) context. (* Nuance)
launch = start a coroutine

No thread is wasted. Waiting is visible, explicit, and safe.

Suspending functions

In Kotlin, waiting is part of the type system:

suspend fun loadUser(): User

This tells the caller: “This function may pause.” Hidden delays? Gone. Cancellation? Easier.

Coroutines encourage structured concurrency: every coroutine has a parent, lifetimes are bounded, leaks are prevented. Virtual threads do not provide this. Comparable behavior requires explicit use of StructuredTaskScope.

Who schedules what?

Key similarity: both models abstract away low-level thread management.

Key difference: who owns and exposes the scheduling model.

Virtual threads: Scheduling is handled transparently by the JVM. Developers write blocking-style code, and the JVM decides when virtual threads run. Threads are cheap, but scheduling is largely an implementation detail of the runtime.

Coroutines: Scheduling is handled by the coroutine framework. Coroutines run on threads, but a coroutine dispatcher determines when and where a coroutine executes. Developers can explicitly choose or configure this dispatcher.

Note: Coroutines still execute on underlying threads, but the coroutine scheduler controls when a coroutine is active. With virtual threads, this control resides entirely within the JVM.

Feature	Threads	Virtual Threads (Java 21+)	Coroutines (Kotlin)
Resource cost	Heavy (1 MB+ per thread)	Light (a few KB per thread)	Very light (bytes per coroutine)
Blocking	Blocks OS thread	Blocks virtual thread (cheap)	Suspends coroutine, does not block thread
Scheduling	OS / JVM	JVM schedules virtual threads	Kotlin scheduler (`Dispatchers`)
Mental model	Threads are doing work	Threads are doing work, but cheap	Coroutine pauses/resumes; waiting is explicit
Structured concurrency	❌	✅ (when using `StructuredTaskScope` since Java 21, optional but without it ❌)	✅ Parent-child relationship, scoped lifetimes
Typical usage	Multi-threaded code	Existing blocking code with many tasks	Async I/O, structured concurrency, modern Kotlin apps
runBlocking	N/A	N/A	Used only for bridging blocking code, e.g., in `main()` or tests; not standard in production

Analogy:

Threads = people blocking chairs while waiting
Virtual Threads = same people, chairs magically multiply
Coroutines = people read a book while waiting, then continue

Interoperability reality

Kotlin runs on the JVM, so:

Coroutines can run on virtual threads
Virtual threads don’t replace suspend
Libraries still need to be coroutine-aware

Using virtual threads doesn’t remove the need to think about async boundaries.

Takeaway

Java asks:

“How can we make blocking cheap?”

Kotlin asks:

“What does it really mean to wait in code?”

Virtual threads: make blocking cheap. Perfect if you have existing blocking code and many I/O-bound tasks, without consuming too much memory.

Coroutines: make waiting explicit and safe. Functions that can pause are visible via suspend, and structured concurrency helps manage lifetimes and cancellation.

Extra nuance – runBlocking

runBlocking is mainly used to bridge blocking code and coroutines, e.g., in main() or tests. In real Kotlin applications, you usually use CoroutineScope with launch or async without runBlocking. RunBlocking examples may be confusing; it is not the standard way to write coroutines in production code.

// Application-wide scope
val appScope = CoroutineScope(Dispatchers.Default)

fun main() {
  appScope.launch {
    println("Coroutine started on thread: ${Thread.currentThread().name}")
    delay(1000L)
    println("Coroutine finished after 1 second")
  }

  println("Main function continues immediately")

  // Keep the JVM alive for demonstration purposes only
  Thread.sleep(1500L)

  // Proper shutdown
  appScope.cancel()
}

What happens here:

CoroutineScope(Dispatchers.Default) + Dispatchers.Default)
- Creates an application-level coroutine scope backed by a shared thread pool.
- The lifecycle must be managed explicitly.
launch { … }
- starts a coroutine without blocking a thread.
delay(1000L)
- Suspends the coroutine without blocking a thread. The underlying thread is free to run other coroutines.
The main function continues immediately.
Thread.sleep(1500L)
- Used here only to keep the JVM alive for demonstration purposes. In real applications (e.g., servers, Android apps), lifecycle management keeps the application running, so this is usually unnecessary.

In short:

Java = “I’m blocking, but it’s cheap.”

Kotlin = “I’m waiting, and everyone knows it.”

Code comparison: Virtual Threads vs Coroutines

Java (Virtual Threads)

Thread virtualThread = Thread.startVirtualThread(() -> {
    try {
        Thread.sleep(500); // simulate waiting for I/O
        System.out.println("Hello from a virtual thread!");
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException(e);
    }
});

virtualThread.join();

Thread.sleep blocks, but it’s cheap
JVM schedules threads for you
Mental model: threads are doing work

Kotlin (Coroutines)

fun greeting() = runBlocking {
    delay(500) // simulate waiting for I/O
    println("Hello from the main coroutine")

    launch {
        delay(500)
        println("Hello from a coroutine!")
    }
}

delay suspends, does not block
launch starts a coroutine that pauses and resumes
No wasted threads; efficient scaling
Waiting is explicit (suspend)

Bonus: Kotlin Coroutines – Cheat Sheet

Concept	What it does	Blocks thread?	Typical usage
`suspend fun`	Marks a function that can pause	No	Functions that perform I/O, waiting, or long-running tasks
`launch { … }`	Starts a coroutine	No	Fire-and-forget tasks, background work
`async { … }`	Starts a coroutine returning a result (`Deferred`)	No	Parallel computations, combine results with `await()`
`runBlocking { … }`	Starts a coroutine in a blocking context	Yes	Only in `main()` or tests, not standard in production
`CoroutineScope`	Manages coroutine lifetimes	–	Application- or component-wide coroutines
`Dispatchers.Default`	Dispatcher for CPU-intensive tasks	No	Computation, background processing
`Dispatchers.IO`	Dispatcher for I/O-intensive tasks	No	Database, network, file I/O
`Dispatchers.Main`	Dispatcher for UI thread (Android)	No	UI updates, user interactions
`delay(time)`	Pauses a coroutine without blocking a thread	No	Simulating wait, sleep-like behavior

Deferred<T> represents a coroutine that will produce a result of type T in the future.
await() suspends the coroutine until the Deferred result is ready, without blocking the underlying thread.
Typical usage: val result = async { computeSomething() }.await()

Sources / Links

From Java to Kotlin – Part IX: Statics and Companion Objects

2026-02-19T08:00:00.000Z

Case 9: You need something that belongs to the class. Not to an instance.

The problem

Sometimes, behavior or data does not belong to an object. It belongs to the type itself.

Constants.
Factory methods.
Utility logic that is conceptually “part of the class”.

In Java, this is easy. Almost too easy.

The Java way

Java has static.

public class User {

    public static final int MAX_NAME_LENGTH = 50;

    public static User anonymous() {
        return new User("Anonymous");
    }

    private final String name;

    public User(String name) {
        this.name = name;
    }
}

Usage:

User user = User.anonymous();
int max = User.MAX_NAME_LENGTH;

Clear.
Familiar.
Unquestioned.

The Kotlin way

Kotlin does not have static.

Instead, it has companion objects.

class User(val name: String) {

    companion object {
        const val MAX_NAME_LENGTH = 50

        fun anonymous(): User =
            User("Anonymous")
    }
}

Usage:

val user = User.anonymous()
val max = User.MAX_NAME_LENGTH

Looks similar.
Feels similar.
But it’s not the same thing.

What is a companion object?

A companion object is:

A real object
Tied to the class
Created once
Able to implement interfaces
Able to be passed around

In other words: - It’s not a language trick. - It’s an object with a name (even if you don’t give it one).

Why not just static?

Because static breaks object composition.

That usually leads to the obvious question: Why?

Object composition works by wiring behavior through replaceable dependencies. Static breaks object composition because it cannot be substituted. Static methods and fields are globally fixed: they cannot be passed around, mocked, or injected. Once you depend on a static, you are hard-wired to that implementation.

Static creates hidden, global dependencies — which is the opposite of composition.

With companion objects, you can:

Inject behavior
Mock logic in tests
Implement interfaces
Keep related logic grouped with the type

Things static simply cannot do.

Java interoperability

From Java, a companion object looks like this:

User.Companion.anonymous();
int max = User.Companion.MAX_NAME_LENGTH;

If that feels verbose, Kotlin has you covered:

class User(val name: String) {

    companion object {
        @JvmStatic
        fun anonymous(): User =
            User("Anonymous")
    }
}

Now Java can call:

User.anonymous();

Why this matters

Kotlin replaces a language keyword with a concept. That concept is more powerful — and more consistent.

You don’t lose statics. You gain objects.

Takeaway

Java answers the question:

“Does this belong to the class?”

Kotlin asks another one:

“What kind of thing is this, really?”

Final note

@JvmStatic tells the Kotlin compiler to generate a real Java static member…

Without it:

class User {
  companion object {
    fun anonymous(): User = User()
  }
}

Java would see: User.Companion.anonymous();

With @JvmStatic Java sees:

User.anonymous();              // generated static method
User.Companion.anonymous();    // still exists

Future direction (Kotlin Dev Day, thank you Jacob!)

Perhaps interesting to know: during Kotlin Dev Day, JetBrains mentioned that in the future companion objects might get a “static sibling” that works almost like Java statics:

class User(val name: String) {
    companion fun anonymous(): User = User("Anonymous")

    companion {
        fun evenMoreAnonymous(): User = User("Anonymous")
    }
}

This is not yet finalized. JetBrains explained that in 95% of public GitHub code, the “object” part of companion objects is not used. The idea is to make the object part optional, as many developers find it confusing.

In short: Kotlin is exploring a way to make companion objects simpler and more accessible, while retaining their power.

Sources / Links

From Java to Kotlin – Part VIII: The Ternary operator vs the Elvis Operator

2026-02-18T08:00:00.000Z

Case 8: You want a sensible default.

If something is missing. Or null. Or both.

The problem

You have a nullable value. You want to use it if it exists. Otherwise, fall back to something reasonable.

This is not advanced logic. It’s everyday defensive programming.

Yet in Java, it rarely looks elegant.

The Java way

Java has the ternary operator:

String name = user.getName();
int length = name != null ? name.length() : -1;
System.out.println("Name length: " + length);

This works.
It’s explicit.
It’s also… noisy.

Things get worse when method calls are involved:

int length = user.getName() != null
    ? user.getName().length()
    : -1;

Or when you start caching intermediate values just to stay readable.

Java does not have a null-aware operator. So you end up spelling out the null check every time.

The Kotlin way

Kotlin combines safe calls with the Elvis operator (?:):

val length = name?.length ?: "Unknown"
println("Name length: $length")

Read out loud, this says:

“Give me the length if name is not null — otherwise, use "Unknown".”

No temporary variables.
No repeated method calls.
No ceremony.

Just intent.

Why is it called the Elvis operator?

Because ?: looks like Elvis Presley.

Really.

It’s the hair… So now you will never unsee this again.

One of my colleagues (hi Jasper 👋) makes sure this is pointed out every single time.

Kotlin does not have a ternary operator

And it doesn’t need one.

In Kotlin:

if is an expression, not a statement (*1)
when is an expression (*1)
?: handles null-coalescing

So instead of:

int x = condition ? a : b;

You write:

val x = if (condition) a else b

The language stays smaller. The intent stays clearer.

Why this matters

Null-handling logic is everywhere. The less visual noise it creates, the easier it is to reason about your code.

The Elvis operator doesn’t add power. It removes friction.

Takeaway

Java makes you spell out your intent. Kotlin lets you express it.

And yes — it really does look like Elvis.

Final note

(*1) As my collegue Riccardo pointed out:

if and when are both expressions ànd statements in Kotlin.

There is actually also a slight difference between the two:

val isEven = Random.nextInt() % 2 == 0
// ✅ if as statement, no else branch, compiles fine
if (isEven) {
  println("Even!")
}
// 🍕🍍if as expression, no else branch, does NOT compile
val isOdd = if (isEven) {
  false
}
// ✅ when as statement, not all branches covered, compiles fine
when {
  isEven -> println("Even!")
}
// 🍕🍍when as expression, not all branches covered, does NOT compile
val isOdd2 = when {
  isEven -> false
}

Sources / Links

From Java to Kotlin – Part VII: Null Safety

2026-02-17T08:00:00.000Z

Case 7: Nulls exist.

Ignoring them doesn’t make them go away.

The problem

NullPointerExceptions are still the most popular Java exception. For all the wrong reasons.

Okay, the NullPointerExceptions aren’t really the problem — They’re the symptom. And Java makes it very easy to create that symptom.

In Java, any reference can be null unless you actively prevent it. Fields, method parameters, return values, collections… all fair game.

Example:

String city = user.getAddress().getCity().toUpperCase();

As you can see, this can explode at three different points, and the compiler is totally fine with it.

user.getAddress() when user is null
user.getAddress().getCity() when user.getAddress() is null
the return value of getCity() when you immediately dereference it (getCity().toUpperCase())

The Kotlin way

val name: String? = null
println(name?.length ?: "Unknown")

Nullability is explicit. Handled by the compiler.

Why this matters

You see nulls before runtime. Not after deployment.

Takeaway

Kotlin turns runtime bugs into compile-time decisions. That’s a trade worth making.

Sources / Links

Kotlin Null Safety

From Java to Kotlin – Part VI: Higher-Order Functions Without Fear

2026-02-16T08:00:00.000Z

Case 6: Passing functions around sounds scary.

Until you try it.

Remember, a higher-order function just is a function that takes another function as a parameter or returns one.

The problem

We want behavior as a parameter. Simple math. Different operations.

The Java way

// Higher-order function with a lambda
private int calculate(int a, int b, Operation operation) {
  return operation.apply(a, b);
}
@FunctionalInterface
interface Operation {
  int apply(int a, int b);
}

Usage:

int r = calculate(5, 3, (a, b) -> a * b);

This works, but requires:

a functional interface
extra ceremony

The Kotlin way

// Higher-order function with a lambda
fun calculate(a: Int, b: Int, operation: (Int, Int) -> Int): Int {
  return operation(a, b)
}

Usage:

val r = calculate(5, 3) { a, b -> a * b }

Functions are first-class citizens. No interfaces required.

Why this matters

Less ceremony lowers the barrier. Lower barriers lead to better abstractions.

Takeaway

Java allows functional programming. Kotlin encourages it.

JDriven Blog

Lazygit

How to Start and Install

Usage

Conclusion

PKI in a Nutshell

PKI in a Nutshell

Intro

Alice and Bob

Encryption

Signing

Certificates

Chain of Trust

Nushell Niceties: Bumping Semantic Version

Nushell Niceties: Transform Values Into Semver Types

Battle-testing Temporal - Part 3

Spawning Child workflows

Acquiring long-term stubs

Sending signals between workflows

The tournament/table signals

Ranking of players

The Tournament Workflow

Temporal Child Workflow support

Learnings so far

Next up…​

Battle-testing Temporal - Part 2

Starting and communicating with a Workflow

Registering the worker

Creating a client and starting a workflow

Supporting replay, continueAsNew and early signals

Continued workflows

Replayed workflows

Adding the Activity into the mix

Learnings so far

Next up…​

Battle-testing Temporal - Part 1

DIY Approach - what I had to start with

how this patterns works

the rough part

Enter - Temporal

Directly translated to Temporal

Why the above code-pattern is not correct anymore

Idiomatic Temporal workflow pattern

Idiomatic Temporal input processing

Workflows, determinism and side effects

Dealing with side effects

Dealing with different results

Embracing Event-Sourcing

Learnings so far

Next up…​

OAuth 2.0 and OIDC Explained with UML

OAuth 2.0 with optional OIDC

Registration

The Flow

Flyway the Right Way

Steps to follow

Nushell Niceties: Checking If Value Is In List Or String Or Key In Record

Kotlin protip: indexed access operator overloading with multiple indices

Example: A two-dimensional grid that stores its data in a one-dimensional Array

Using the Grid

Why overload with multiple indices?

Summary

Bonus: From Java to Kotlin – Part XII: Sealed Classes vs Enums / Polymorphism

The problem

Java 'the old way': Enums or Class Hierarchies

Using Enums

Using Class Hierarchies

Java 'the new way': Sealed Classes with Exhaustive Switch (Java 21+)

The Kotlin way: Sealed Classes

Polymorphism without when

Short catch-up: What is Polymorphism?

Enum vs Sealed Class vs Data Class

Takeaway

Sources / Links

From Java to Kotlin – Part XI: The Builder Pattern vs Type-safe Builders / DSL

The problem

The Java way

The Kotlin way

But what if the object becomes complex?

A quick note: what is a DSL?

Next up…

Next up…

Next up…

Polymorphism without `when`