Practice II · Java / Kotlin
JVM systems in the difficult middle.
Desktop application code, long-lived server state, authored content, rendering, persistence, and the machinery needed to prove that several processes agree. This is the JVM side of the portfolio.
- Languages
- Java · Kotlin · GLSL
- Surfaces
- Compose desktop · server runtimes · client rendering · browser tooling
- State
- Coroutines · serialised content · databases · queues · realtime events
- Delivery
- Gradle · Java 21 · packaging · cross-process and client-observable tests
01 / Desktop product
A launcher is application code, interface, and distribution at once.
My current professional project is a standalone launcher and client built in Java, Kotlin, and Compose by a two-person launcher team. I work directly in the shared desktop codebase as a Senior Software Engineer. The diagram stays at the published product boundary; private architecture, feature attribution, roadmap, and unreleased work do not belong here.
- 01 / ROLE
Senior Software Engineer working directly on the launcher and client.
- 02 / TEAM
One of two launcher developers, so product and implementation decisions stay close together.
- 03 / BOUNDARY
The useful public facts are here. The private implementation stays private.
02 / Modular platform
Thirteen products, one JVM ecosystem.
Matcha! is an independent suite spanning competition, progression, delivery, commerce, player state, automation, and live systems. Each product can stand alone. Shared events, identities, persistence, and operator expectations still have to compose without turning the suite into one inseparable application.
queues · ratings · battle policy · data-defined effects
tasks · encounters · jobs · timed world state
markets · durable delivery · queued matching
handoff · migration · scripting and authored rules
Compiled machinery; authored behaviour.
Journey separates reusable runtime state from tasks, zones, flags, timelines, encounters, and scripts that can be revised as content.
One market, several surfaces.
Bazaar keeps listing, bidding, settlement, history, and recovery in the domain layer while game and browser clients read the same market state.
Recovery is part of the system.
Delivery, handoff, cross-node state, and market writes all have explicit recovery paths.
03 / Verification
Test what another process can actually observe.
A green unit test is not enough when the behaviour crosses servers, a shared store, a proxy, and a real client. The Bazaar harnesses move from domain tests to live multi-process arrangements, then assert the state visible at the edge.
- PROCESS
Each participating runtime boots as the thing it represents, not as a mocked call graph.
- STATE
Shared persistence and cross-node replication are exercised under their real boundaries.
- PROOF
The final assertion is client-observable behaviour: the result that a user would actually encounter.
04 / Public rendering work
Rendering infrastructure that other work can build on.
Veil is a public Java and GLSL collaboration covering models, render targets, depth, shaders, and post-processing across loaders. It is infrastructure rather than a single visual effect: the useful unit is the render path another project can depend on.