Technology Stack

LoomCache is built around Java virtual threads, a versioned binary protocol, and bounded backpressure. It relies on modern Java capabilities rather than pulling in external bloat.

Small Core Dependency Surface

LoomCache core explicitly avoids external cache engines and broad application frameworks in the runtime data path. The core datastore and clustering engine are written in plain Java.

Tip

By keeping the core dependency surface small, we reduce the security attack surface and can reduce cold-start overhead.

The minimal dependency footprint:

Component	Technology	Purpose
Serialization	Kryo 5.6.2 + LoomCache Compact	High-performance binary serialization with class-specific serializer precedence, schema-evolving Compact records, GenericRecord field access, and a global serializer SPI
Hashing	Stable 32-bit key hash	Consistent hashing for partition routing
Networking	Blocking ServerSocket + virtual thread per connection	Standard blocking I/O yielding on virtual threads
Consensus	Custom Raft	No external consensus dependency
Metrics	Micrometer	Prometheus-compatible observability

No Netty in the core protocol runtime. No Spring (in core). No external cache libraries. The shipped socket transports use JSSE; Netty appears only when applications build their own native TLS contexts.

Virtual Threads (Project Loom)

The backbone of LoomCache’s concurrency is Java 25 Virtual Threads.

Java Virtual Threads (Project Loom)

Many lightweight virtual threads multiplexed over a few OS carrier threads.

VT

VT

VT

OS Thread 1

Carrier

OS Thread 2

Carrier

Traditional OS threads are heavy, requiring memory per thread and context-switching overhead. Thread per request scaling has historically hit a wall at a few thousand concurrent connections.

LoomCache uses a virtual-thread-per-task model (Thread.ofVirtual().start() per connection):

• Every incoming network connection gets its own extremely lightweight virtual thread.
• Blocking I/O operations (like writing to the TCP socket or reading from the WAL) do not block OS threads. They just yield the virtual thread.
• This keeps the networking model simple under high concurrency without requiring a reactive programming stack.

Why This Matters

Model	Connections	Complexity	Memory per Connection
Platform thread per connection	~10,000	Moderate (blocking code, high thread cost)	~1 MB
Reactive (WebFlux)	~100,000	Very High (reactive chains)	~10 KB
Virtual Threads	High (platform dependent)	Low (blocking code)	~1 KB

Note

The figures above are illustrative platform characteristics of the JVM virtual-thread model, not LoomCache-specific benchmark results.

LoomCache keeps the simplicity of traditional blocking code while benefiting from JVM virtual-thread scheduling. When a virtual thread blocks on socket.read() or fsync(), the carrier OS thread can run other work.

Java 25 Features

LoomCache leverages cutting-edge Java 25 LTS features:

• Virtual Threads — Per-connection lightweight threads; each accepted Socket is handed off to its own virtual thread so blocking I/O code can scale without callback chains
• Executors.newVirtualThreadPerTaskExecutor() — Used for structured fan-out in graceful shutdown, cross-group scatter queries, and health probes
• ScopedValues — Efficient immutable request-context propagation across virtual threads
• Virtual-thread-friendly locking — Hot paths use ReentrantLock where appropriate; synchronized blocks remain in low-contention lifecycle and membership guards

Project Stats

Metric	Value
Maven modules	6 (loom-common, loom-server, loom-client, loom-cli, loom-spring-boot, loom-integration-tests)
Production Java files in listed modules	705
Test Java files	1,213
Test method count	Varies with parameterized-test expansion; use the Maven reactor for current evidence
Protocol surface	Versioned binary client/server protocol
Server Java	25 (--enable-preview)
Client Java	17+
Default binary port	5701 for JVM/Spring Boot config; 7654 in Docker samples
Default metrics port	9090