Skip to content

Technology Stack

LoomCache is built around Java virtual threads, a versioned binary protocol, and bounded backpressure. It relies on modern Java capabilities rather than large external frameworks. This page describes the core dependencies, the virtual-thread concurrency model, and the Java 25 features that support it.

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.

The following table lists the core dependencies:

ComponentTechnologyPurpose
SerializationKryo 5.6.2 + LoomCache CompactHigh-performance binary serialization with class-specific serializer precedence, schema-evolving Compact records, GenericRecord field access, and a global serializer SPI
HashingStable 32-bit key hashConsistent hashing for partition routing
NetworkingBlocking ServerSocket + virtual thread per connectionStandard blocking I/O yielding on virtual threads
ConsensusCustom RaftNo external consensus dependency
MetricsMicrometerPrometheus-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.

LoomCache builds its concurrency model on 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: each thread consumes memory and adds context-switching overhead. Thread-per-request scaling has historically stalled 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 (such as writing to the TCP socket or reading from the WAL) do not block OS threads. They yield the virtual thread instead.
  • This keeps the networking model simple under high concurrency without requiring a reactive programming stack.
ModelConnectionsComplexityMemory per Connection
Platform thread per connection~10,000Moderate (blocking code, high thread cost)~1 MB
Reactive (WebFlux)~100,000Very High (reactive chains)~10 KB
Virtual ThreadsHigh (platform dependent)Low (blocking code)~1 KB

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.

LoomCache uses the following 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 — 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
MetricValue
Maven modules6 (loom-common, loom-server, loom-client, loom-cli, loom-spring-boot, loom-integration-tests)
Production Java files in listed modules705
Test Java files1,213
Test method countVaries with parameterized-test expansion; use the Maven reactor for current evidence
Protocol surfaceVersioned binary client/server protocol
Server Java25 (--enable-preview)
Client Java17+
Default binary port5701 for JVM/Spring Boot config; 7654 in Docker samples
Default metrics port9090

To see how these building blocks combine at runtime, read Raft Clustering and Networking Layer.

LoomCache is an independent open-source project. It is not affiliated with, endorsed by, or sponsored by Hazelcast, Inc. or by any other company whose products are named in this documentation. “Hazelcast” is a trademark of Hazelcast, Inc.; references to it are nominative and describe only migration and comparison. All other product and company names are trademarks of their respective owners and are used for identification purposes only.