CodeClash: The Bare-Metal Java Arena Where Code Competes in Real Time

A Spring Boot 1v1 coding platform that keeps the stack lean, executes solutions locally, and turns algorithm practice into a duel system with Elo, rooms, and match state.

8 min read • View on GitHub • More from iamkrish-0708

Two programmers face each other across a compact mechanical arena while a judge mechanism sits between them, feeding code into a compiler furnace and sending back pass or fail signals. The scene explains that CodeClash is both a competition system and a local execution engine, not just a practice site. — CodeClash turns a coding judge into part of the game loop, so the execution engine is the spectacle as much as the match itself.

Key Takeaways

CodeClash’s main trick is not the UI, it is the judge: Java submissions are compiled and run locally with tight limits, so the platform feels immediate and self-contained.
The product is built around competition pressure, with rooms, matches, and Elo turning practice problems into head-to-head duels.
The stack stays deliberately lean, pairing Spring Boot with a no-framework frontend and a local-first database setup.
That simplicity is also the ceiling, because local execution is elegant for latency but harder to scale and isolate safely at high volume.

Why CodeClash Feels Different From a Normal Coding Site

Most coding platforms are built around a quiet assumption: correctness is the point, and the judge is backstage. CodeClash flips that. It makes the judge feel like part of the product, then wraps it in a 1v1 duel loop where the pressure is the feature.

That changes the emotional shape of practice. You are not just solving a problem, you are racing another person through a room, a match, and a rating update. The repo’s identity comes from that combination of competition and execution, not from any single framework choice.

The result is unusually direct. The frontend is plain enough to stay out of the way, the backend is lean, and the interesting work happens where code is compiled, run, and judged under strict limits.

The Engine Room: Running Java Code Locally

The centerpiece is LocalJavaExecutionService. Instead of pushing submissions to a separate judge cluster, CodeClash writes the code to a temp directory, detects the public class name with a regex, compiles it with javac, and launches it with java through ProcessBuilder.

This diagram shows the part of CodeClash that matters most: how untrusted Java gets isolated, compiled, timed, and compared without leaving the host process.

That is a small amount of code with a lot of responsibility. The service uses a temp workspace, a memory cap, and per-test-case timeouts to keep the loop bounded. It also avoids forcing a single boilerplate class name, which makes the experience closer to a real editor than a toy judge.

private static final Pattern CLASS_NAME_PATTERN =
    Pattern.compile("public\\s+class\\s+([A-Za-z0-9_]+)");

Path tempDir = Files.createTempDirectory("codeclash-");
Process compile = new ProcessBuilder("javac", sourceFile.toString())
    .directory(tempDir.toFile())
    .start();

A close view of a code sheet moving through a sequence of mechanical stations: a magnifying glass extracts the class name, a drawer holds a temp directory, a compiler press stamps javac, and a timer and memory gauge guard the runtime chamber. The image explains the service pipeline that makes local execution feel controlled instead of ad hoc. — The execution path is not hidden behind infrastructure theater. It is a sequence of explicit mechanical steps with clear failure points.

How a Match Moves From Lobby to Winner

The execution engine is only half the story. CodeClash also models the social layer around the contest: Room for the lobby, Match for the active duel, and MatchPlayer for linking participants to a contest state that can grow beyond simple 1v1.

That split matters. A room can exist before the game starts, then become a tracked match once the contest is live. The data model keeps the lobby logic and the scoring logic distinct, which is the right kind of separation for something that wants both responsiveness and persistence.

Phase	Room	Match	What it tracks
Lobby	Host and guest gather	Not started yet	Waiting state and participant pairing
Active duel	Promotes into play	The live contest	Problem, status, and outcome
Aftermath	Preserves context	Stores the result	Winner, loser, or draw

Why the Domain Model Is Built for Competition

The user model is not just authentication plumbing. It already assumes ranking, persistence, and outcomes that matter over time. Rating, wins, losses, and draws are first-class fields, and authProvider suggests the project expects users to arrive through more than one door.

@Entity
public class User {
    private int rating = 1200;
    private int wins;
    private int losses;
    private int draws;
    private String authProvider;
}

That is a product decision disguised as schema design. If you store Elo-like state from the start, the platform is not just a sandbox. It is a competitive system where history changes the next match.

Field	Why it exists	What it signals
rating	Ranks players over time	Competition is persistent
wins / losses / draws	Records match outcomes	The game loop matters
authProvider	Supports local and Google login	The platform expects mixed identity sources

A Lean Stack With a Strong Opinion

The stack stays intentionally modest. Spring Boot handles the server side, vanilla JavaScript handles the browser, H2 makes local setup simple, and MySQL is there when the project moves beyond a laptop. Docker and deployment config sit beside that, so the repo can move from clone to running system without much ceremony.

That is a specific opinion about developer experience. Instead of paying the complexity tax of a heavy frontend framework, the project keeps the surface area small and puts the energy into match flow and execution reliability.

Layer	CodeClash	Typical heavier app
Frontend	Vanilla JS and static assets	React or Vue build pipeline
Local dev	H2-first, low friction	More setup and more moving parts
Execution	Local ProcessBuilder judge	External judge service
Deployment	Docker and simple app config	Multiple services and queues

The tradeoff is obvious, and that is the point. CodeClash optimizes for a direct path from idea to live duel, not for infrastructure drama.

What CodeClash Chooses Not to Be

It is not trying to look like a sprawling hosted judge with opaque internals. It is also not trying to be a frontend showcase. The repo’s most persuasive move is refusal: it leaves out complexity that does not improve the duel.

Question	Conventional judge	CodeClash
Where does code run?	In a separate remote judge	Locally through a lean Java service
What does the user feel?	Submit and wait	Compete in real time
What is optimized?	General-purpose infrastructure	Latency, clarity, and control
What is the core artifact?	A result from a queue	A live competitive match

The Tradeoff

The same choice that makes CodeClash elegant also defines its ceiling. Local execution is fast and understandable, but it is harder to scale safely than a hardened distributed judge. That is the real story here: the repo makes a smart, opinionated bet, and it owns the consequences.

That makes the project interesting in a way many polished demos are not. It is a system with a visible mechanism, a clear competitive loop, and a narrow focus. The ambition is real, but so is the restraint.