DEV Community: Machine coding Master

Reader-Writer Lock in Java: Solving the Library Problem in LLD

Machine coding Master — Mon, 28 Sep 2026 08:54:57 +0000

Reader-Writer Lock in Java: Solving the Library Problem in LLD

In Java concurrency and machine coding rounds, synchronizing read-heavy systems with coarse-grained locks is an immediate red flag. The classic "Library Problem"—where thousands browse books while librarians infrequently update the catalog—tests whether you understand lock contention and read-write access asymmetry.

The Mistake Most Candidates Make

Slapping synchronized or a plain ReentrantLock across all operations, serializing every reader and collapsing system throughput to a single thread.
Ignoring writer starvation by defaulting to unfair lock policies where an endless stream of readers completely starves pending writes.
Omitting proper resource cleanup by failing to place unlock() inside finally blocks, leading to permanent lock leaks when runtime exceptions occur.

The Right Approach

Core mental model: Multiple readers can safely access shared state concurrently, but a writer demands absolute, exclusive ownership before mutating data.
Key entities/classes: ReadWriteLock, ReentrantReadWriteLock, Lock, CatalogManager.
Why it beats the naive approach: It eliminates reader-on-reader lock contention entirely while maintaining strict consistency boundaries during updates.

Shameless plug: javalld.com has full LLD implementations with step-by-step execution traces — free to use while prepping.

The Key Insight (Code)

public class BookCatalog {
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock(true);
    private final Lock readLock = rwLock.readLock(), writeLock = rwLock.writeLock();
    private final Map<String, Book> books = new HashMap<>();

    public Book get(String id) {
        readLock.lock();
        try { return books.get(id); }
        finally { readLock.unlock(); }
    }

    public void put(Book book) {
        writeLock.lock();
        try { books.put(book.id(), book); }
        finally { writeLock.unlock(); }
    }
}

Key Takeaways

ReentrantReadWriteLock maximizes read-heavy performance by splitting synchronization into shared read locks and exclusive write locks.
Enabling fairness (fair = true) prevents writer starvation by prioritizing waiting writer threads over newly arriving reader threads in the acquisition queue.
Lock downgrading (acquiring read lock while holding write lock, then releasing write lock) is fully supported, whereas lock upgrading is impossible and triggers deadlocks.

Full working implementation with execution trace available at https://javalld.com/learn/reader-writer

Stop Bloating Vector Indexes: Slicing Embeddings with Spring AI and Pgvector

Machine coding Master — Sun, 27 Sep 2026 08:38:38 +0000

Stop Bloating Vector Indexes: Slicing Embeddings with Spring AI and Pgvector

Your Postgres instance is quietly running out of RAM because you are indexing default 1536-dimensional vectors for chunks that require a fraction of that depth. Matryoshka Representation Learning (MRL) lets you safely prune up to 75% of those dimensions without sacrificing retrieval recall, slashing your pgvector index footprint overnight.

Why Most Developers Get This Wrong

Assuming embedding dimensions are immutable: Blindly persisting 1536d or 3072d vectors directly into pgvector and wondering why the HNSW graph spills out of shared_buffers directly to disk.
Truncating arbitrary embeddings: Slicing vectors generated by standard non-MRL models (like legacy Ada models), which completely breaks vector space geometry and destroys cosine similarity.
Over-engineering with client-side PCA: Adding complex dimensionality reduction pipelines in Java services instead of using models specifically pre-trained to nest semantic information in prefix sub-vectors.

The Right Way

Let MRL models pack the highest-variance features into the first $N$ dimensions, then slice the output directly through Spring AI during ingestion and query execution.

Deploy MRL-native models such as text-embedding-3-small or nomic-embed-text.
Enforce truncated dimensions at the application layer using Spring AI's native client configuration.
Re-index pgvector storage from vector(1536) down to vector(512) or vector(256), reducing index build times and query latencies exponentially.
Implement an optional two-stage retrieval: perform fast approximate nearest neighbors (ANN) on 256d vectors, then re-rank candidate documents if your domain requires razor-thin precision.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

Show Me The Code

Configure your Spring AI bean to slice dimensions at the API boundary, keeping Postgres lean:

@Configuration
public class VectorStoreConfig {
    @Bean
    public EmbeddingModel embeddingModel(OpenAiConnectionProperties props) {
        var options = OpenAiEmbeddingOptions.builder()
            .model("text-embedding-3-small")
            .dimensions(512) // MRL slices 1536 -> 512 natively
            .build();
        return new OpenAiEmbeddingModel(new OpenAiApi(props.getApiKey()), MetadataMode.EMBED, options);
    }
}
// Postgres schema:
// ALTER TABLE vector_store ALTER COLUMN embedding TYPE vector(512);
// CREATE INDEX ON vector_store USING hnsw (embedding vector_cosine_ops);

Key Takeaways

70%+ RAM reduction: Moving from 1536 to 512 dimensions drops Postgres vector memory pressure by roughly 66% while retaining over 98% of retrieval recall.
Zero client-side math: Spring AI handles the dimension constraint natively through OpenAiEmbeddingOptions, offloading dimensionality management to the model provider.
HNSW stays in memory: Smaller vectors keep your graph indices inside Postgres shared_buffers, eliminating costly NVMe disk paging during similarity scans.

Stop Losing Chunk Context: Anthropic's Contextual Retrieval with Spring AI and Virtual Threads

Machine coding Master — Sat, 26 Sep 2026 07:59:30 +0000

Stop Losing Chunk Context: Anthropic's Contextual Retrieval with Spring AI and Virtual Threads

Naive chunking destroys document semantics, causing over half of production RAG retrieval queries to miss critical context. Prepending dynamic contextual summaries via Anthropic’s prompt caching—executed concurrently across chunks using Java Virtual Threads—fixes this without blowing your latency or LLM budget.

Why Most Developers Get This Wrong

Relying on naive splitters: Splitting strictly by token limits or arbitrary overlaps yields orphan chunks like "EBITDA dropped 4%," with zero metadata indicating the company or fiscal quarter.
Sequential LLM enrichment: Processing chunks sequentially against an LLM turns document ingestion pipelines into a multi-hour operational bottleneck.
Ignoring prompt caching: Re-sending the entire parent document for every single chunk annotation burns thousands of input tokens and bankrupts your RAG budget.

The Right Way

Inject LLM-generated chunk context using Claude 3.5 Sonnet and prompt caching, fanned out concurrently via Java Virtual Threads into a hybrid BM25 and vector index.

Enable prompt caching on the parent document so all chunk-enrichment calls read the large parent context from cache at an 80-90% discount.
Fan out chunk-enrichment calls concurrently inside a Spring AI DocumentTransformer using an unbounded Virtual Thread executor.
Format chunks as [Context: {summary}]\n\n{original_text} before generating embeddings and BM25 lexical tokens.
Query your vector store (e.g., PgVector) using Spring AI's hybrid search API to capture both semantic similarity and exact keyword anchors.

Show Me The Code

public class ContextualTransformer implements DocumentTransformer {
    private final ChatModel chatModel; // Configured for Claude 3.5 Sonnet

    public List<Document> apply(List<Document> chunks, Document parentDoc) {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            var futures = chunks.stream().map(chunk -> executor.submit(() -> {
                String prompt = """
                    <document>%s</document>
                    Situate this chunk within the parent document in 2-3 concise sentences:
                    <chunk>%s</chunk>""".formatted(parentDoc.getText(), chunk.getText());
                String context = chatModel.call(prompt);
                return chunk.mutate().text(context + "\n\n" + chunk.getText()).build();
            })).toList();
            return futures.stream().map(Future::join).toList();
        }
    }
}

Key Takeaways

Naive chunking is obsolete; Contextual Retrieval eliminates chunk ambiguity by embedding parent-document context directly into the text.
Virtual Threads give you non-blocking, massive LLM concurrency in Java without the mental overhead of Reactive Streams.
Prompt caching makes parallel contextual ingestion economically viable by slashing input token costs on parent documents.

Shameless plug: javalld.com has full LLD implementations with step-by-step execution traces — free to use while prepping.

Stop Polluting Your Domain with Static Factories: Clean Validation with Java 25 Flexible Constructor Bodies

Machine coding Master — Sun, 20 Sep 2026 07:55:52 +0000

Stop Polluting Your Domain with Static Factories: Clean Validation with Java 25 Flexible Constructor Bodies

For years, Java forced us to write bloated static factory methods just to validate arguments before calling super(). With Java 25 LTS standardizing flexible constructor bodies (JEP 492) in 2026, you can finally run pre-construction logic safely inside the constructor where it belongs.

Why Most Developers Get This Wrong

Cluttering clean domain entities with private constructors and artificial of() or create() static factories purely to run Objects.requireNonNull() or value boundary checks.
Cramming complex validation and sanitization logic into ugly, nested inline static helper calls like super(sanitize(arg), validate(otherArg)).
Accidentally risking uninitialized reference leakage by attempting workarounds that bypass Java's object lifecycle invariants.

The Right Way

Execute validation, argument transformation, and defensive copies directly in the constructor prologue before invoking super() or this().

Place fail-fast argument checks at the very top of your constructor so downstream allocation halts immediately on bad input.
Transform incoming values (such as trimming strings, sanitizing payloads, or converting units) into local variables before passing them up the inheritance chain.
Rely on Java 25's compiler-enforced pre-construction context, which explicitly prohibits any reference to this until after super() executes.
Delete redundant static factories that exist solely to orchestrate pre-super checks and restore natural, object-oriented instantiation.

Show Me The Code

public class AuditedOrder extends Order {
    private final Instant auditTimestamp;

    public AuditedOrder(String orderId, BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Amount must be positive: " + amount);
        }
        String normalizedId = Objects.requireNonNull(orderId).trim().toUpperCase();
        super(normalizedId, amount);
        this.auditTimestamp = Instant.now();
    }
}

Key Takeaways

Flexible constructor bodies (JEP 492) make constructors the single source of truth for class invariants again, killing unnecessary static factory patterns.
The constructor prologue is safe by design: the compiler strictly prohibits reading fields, assigning to instance variables, or referencing this before super().
Standardizing on this pattern across your Java 25 services creates cleaner, more idiomatic object hierarchies with far less ceremonial boilerplate.

If you're prepping for interviews, I've been building javalld.com — real machine coding problems with full execution traces.

Java Concurrency LLD: Build a Custom BlockingQueue From Scratch

Machine coding Master — Sun, 13 Sep 2026 07:37:47 +0000

Java Concurrency LLD: Build a Custom BlockingQueue From Scratch

At Apple and Amazon, implementing a thread-safe BlockingQueue is one of the most frequent concurrency challenges in Low-Level Design (LLD) interviews. It immediately exposes whether you understand thread coordination, thread-safe state mutation, and JVM internals, or merely rely on off-the-shelf utilities.

The Mistake Most Candidates Make

Relying on intrinsic locks (synchronized) with notifyAll(), which triggers the "thundering herd" problem by waking up both producers and consumers simultaneously.
Checking capacity bounds using an if statement instead of a while loop, leaving the queue vulnerable to state corruption via spurious wakeups.
Failing to structure lock acquisition with a proper try-finally block, which causes unrecoverable deadlocks if a thread encounters an unexpected exception or interruption.

The Right Approach

Core mental model: Decouple producer and consumer wait states using an explicit lock tied to two independent condition queues.
Key entities/classes: ReentrantLock, Condition (notFull, notEmpty), array-based circular buffer (Object[]).
Why it beats the naive approach: Direct signaling via signal() wakes only the specific thread capable of making progress (producers wake consumers and vice versa), drastically reducing context switching.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

The Key Insight (Code)

public void put(E item) throws InterruptedException {
    lock.lockInterruptibly();
    try {
        while (count == items.length) {
            notFull.await();
        }
        enqueue(item);
        notEmpty.signal();
    } finally {
        lock.unlock();
    }
}

Key Takeaways

Dual Conditions, Single Lock: Bind two separate Condition instances (notFull, notEmpty) to one ReentrantLock to isolate wait-sets for producers and consumers.
Always Guard with while: Always check wait conditions inside a while loop to re-verify state invariants after waking up from await().
Symmetric Cross-Signaling: Modifying the queue must notify the opposite condition—producers signal notEmpty after adding an element, and consumers signal notFull after removing one.

Full working implementation with execution trace available at https://javalld.com/learn/blocking-queue

Stop Slamming Downstream Services: Singleflight Request Coalescing with Java Virtual Threads

Machine coding Master — Sat, 12 Sep 2026 07:21:49 +0000

Stop Slamming Downstream Services: Singleflight Request Coalescing with Java Virtual Threads

Virtual threads solved your JVM I/O bottlenecks, but downstream internal services are now on fire because 50,000 concurrent threads are fetching the exact same cache miss simultaneously. You do not need distributed locks or larger database instances; you need the Singleflight request coalescing pattern inside your JVM.

Why Most Developers Get This Wrong

Reaching for distributed locking: Slapping Redisson or Redis locks over hot cache misses adds unnecessary network hops and operational latency for what is fundamentally an in-process duplicate query problem.
Blocking with synchronized blocks: Using coarse ReentrantLock or synchronized guards pinned carrier threads in early Loom setups and destroys virtual thread scalability across high-throughput services.
Relying purely on TTL caches: When a hot Redis or Caffeine key expires under 20k RPS, raw uncoordinated reads trigger immediate thundering herds across downstream gRPC/REST endpoints.

The Right Way

Suppress duplicate concurrent calls locally by routing identical in-flight keys to a single downstream execution using lock-free coordination.

Use a ConcurrentHashMap to register in-flight CompletableFuture instances keyed by query identity.
The first virtual thread registers the promise and triggers the downstream RPC, while subsequent threads simply wait on the shared future.
Leverage CompletableFuture.join()—virtual threads unmount cleanly from OS carrier threads while awaiting the result.
Automatically evict keys in a finally block or completion callback so future requests trigger fresh executions.

Show Me The Code

Here is an idiomatic, lock-free Singleflight implementation using standard Java concurrency utilities:

public class Singleflight<K, V> {
    private final ConcurrentHashMap<K, CompletableFuture<V>> inFlight = new ConcurrentHashMap<>();

    public V execute(K key, Supplier<V> task) {
        return inFlight.computeIfAbsent(key, k -> {
            var future = new CompletableFuture<V>();
            Thread.ofVirtual().start(() -> {
                try { future.complete(task.get()); }
                catch (Throwable ex) { future.completeExceptionally(ex); }
                finally { inFlight.remove(k); }
            });
            return future;
        }).join();
    }
}

Key Takeaways

Protect your downstream: Virtual threads can absorb massive ingress spikes; without in-JVM coalescing, that traffic acts as a self-inflicted DDoS against internal dependencies.
Lock-free coordination wins: Combining ConcurrentHashMap.computeIfAbsent() with CompletableFuture eliminates thread contention while keeping memory overhead negligible.
Clean up immediately: Always evict keys in finally blocks to avoid memory leaks and prevent transient downstream exceptions from permanently poisoning future callers.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Stop Naive Vector Lookup: Boost RAG Recall with Spring AI HyDE Query Rewriting

Machine coding Master — Thu, 13 Aug 2026 04:27:16 +0000

Stop Naive Vector Lookup: Boost RAG Recall with Spring AI HyDE Query Rewriting

Direct vector similarity search on raw, short user queries is absolute poison for enterprise RAG recall. In 2026, shipping naive query-to-embedding lookups without query transformation is an amateur mistake that degrades retrieval precision by over 40%.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

Why Most Developers Get This Wrong

Vector Space Misalignment: Embedding short, asymmetric user queries (e.g., "auth failure fix") directly against long, dense document chunk embeddings causes severe distance drift in vector space.
Over-reliance on Pure Cosine Similarity: Assuming top-k cosine similarity on raw text will magically surface domain-specific context without context expansion or intent translation.
Custom Glue Code Anti-patterns: Hardcoding messy LLM prompt loops for query expansion instead of leveraging standard, composable transformation abstractions.

The Right Way

Bridge the asymmetric search gap by generating a hypothetical answer via LLM first, then embedding that synthetic document to hit your vector store.

Implement a Hypothetical Document Embedding (HyDE) strategy using Spring AI's query transformation framework.
Transform a raw 4-word prompt into a zero-shot synthetic response before generating vector embeddings.
Pass the transformed Query object through Spring AI's modular pipeline before reaching your VectorStore.
Pair HyDE with hybrid search in pgvector or Milvus to eliminate retrieval hallucination risks on exact keyword edge cases.

Show Me The Code (or Example)

@Bean
public QueryTransformer hydeTransformer(ChatModel chatModel) {
    String template = "Given the user query, generate a short hypothetical document that answers it.\nQuery: {query}";
    return RewriteQueryTransformer.builder()
            .withChatModel(chatModel)
            .withPromptTemplate(template)
            .build();
}

public List<Document> retrieveRelevantDocs(String userQuery) {
    Query query = new Query(userQuery);
    Query hydeQuery = hydeTransformer.transform(query);
    return vectorStore.similaritySearch(hydeQuery);
}

Key Takeaways

Raw user queries and target document chunks inhabit different semantic spaces; HyDE maps queries into answer space before distance computation.
Spring AI's QueryTransformer abstraction standardizes query rewriting, multi-query generation, and HyDE into reusable, testable beans.
Stop blaming your vector database for poor search relevance when the real bottleneck is your raw input query.

Stop Wasting Sprint Hours on SAST Backlogs: Wire SonarLint CLI into Claude Code

Machine coding Master — Wed, 12 Aug 2026 04:23:52 +0000

Stop Wasting Sprint Hours on SAST Backlogs: Wire SonarLint CLI into Claude Code

Hand-fixing 400+ static analysis violations before a release sprint is an obsolete waste of senior engineering hours. By piping SonarLint CLI's SARIF output directly into headless Claude Code terminal loops, you can deterministically clear enterprise Java quality gates on autopilot.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Why Most Developers Get This Wrong

Treat AI remediation as unconstrained chat sessions, causing hallucinated API calls and broken ASTs across legacy Spring Boot services.
Copy-paste SonarQube rule IDs (e.g., java:S2095 resource leaks) manually into web interfaces instead of passing structured diagnostic artifacts to the agent.
Rely on naive regex replacements that destroy test coverage and fail secondary cognitive complexity checks.

The Right Way

Feed headless Claude Code agent loops structured SARIF diagnostic data to enforce deterministic, rule-bound Java code remediation.

Execute sonarlint-cli locally to export machine-readable SARIF reports containing line-level AST locations and rule keys.
Invoke claude -p in headless terminal loops, constraining the agent with strict execution boundaries (e.g., converting raw Try-Finally blocks to Try-With-Resources).
Validate every automated patch using localized mvn test-compile feedback loops before auto-committing clean code.
Prevent infinite repair loops by hard-capping agent attempt budgets per violation.

Show Me The Code (or Example)

# 1. Run SonarLint CLI to generate structured SARIF diagnostics
sonarlint-cli --src "src/main/java" --format sarif > .sonar-report.sarif

# 2. Trigger headless Claude Code remediation loop
claude -p "Read .sonar-report.sarif. For each issue in Java files:
1. Locate target file and precise line region.
2. Refactor code to resolve the specific Sonar rule ID without changing business logic.
3. Verify fix via 'mvn test-compile -Dtest=UnitTests'.
4. Commit: 'fix(sast): resolve [rule-id]'." \
--allowedTools "Bash,FileEdit,FileRead" --auto-approve

Key Takeaways

SARIF JSON is the standard contract between static analysis tools and autonomous LLM coding agents.
Always enforce inline compilation and test checks (mvn test-compile) inside your agent execution parameters.
Move your role from mechanical tech-debt cleaner to pipeline architect supervising multi-file agentic refactoring.

Stop Guessing Micro-Stalls: Debugging JIT Safepoint Latency with JDK 26 JFR

Machine coding Master — Tue, 11 Aug 2026 04:03:18 +0000

Stop Guessing Micro-Stalls: Debugging JIT Safepoint Latency with JDK 26 JFR

If your high-throughput virtual thread service suffers from random p99.9 latency spikes while CPU and heap metrics look completely calm, you are likely hitting JIT safepoint starvation. In JDK 26, single uncounted loops can freeze tens of thousands of mounted virtual threads simultaneously, leaving legacy APMs completely blind.

Why Most Developers Get This Wrong

Blaming Garbage Collection blindly: Developers waste days tuning G1GC/ZGC parameters when jdk.GarbageCollection JFR events show sub-millisecond pauses during p99 spikes.
Assuming Virtual Threads isolate latency: Virtual threads unmount during I/O, but an uncounted JIT loop stalls the underlying carrier thread—blocking global safepoints for the entire JVM instance.
Relying on aggregated APM metrics: Standard APMs aggregate latency over 10-second windows, completely obscuring 40ms stop-the-world VM safepoint stalls.

The Right Way

Pinpoint exact code paths causing safepoint delays by correlating JFR jdk.SafepointWait and jdk.ExecuteVMOperation events directly with JIT loop optimizations.

Enable JFR safepoint profiling in production to catch carrier threads that fail to reach a safepoint prompt.
Trace the waitThread field in jdk.SafepointWait events to pinpoint the exact OS/carrier thread holding the JVM hostage.
Instruct the C2 compiler to insert safepoint polls into long-running loops using JVM flags.
Correlate micro-stalls with carrier thread stack traces captured during the stall window.

Show Me The Code

Here is how an uncounted loop delays JVM safepoints across thousands of virtual threads, and how to capture it:

// Culprit: Long-running uncounted primitive loop (C2 eliminates safepoint checks by default)
public double computeAggregates(double[] rawData) {
    double sum = 0.0;
    for (int i = 0; i < rawData.length; i++) { // Stalls global safepoint if array is large
        sum += Math.sin(rawData[i]);
    }
    return sum;
}

// 1. Enable via JVM args in JDK 26:
// -XX:+UseCountedLoopSafepoints -XX:CompileCommand=option,computeAggregates,UseCountedLoopSafepoints

// 2. Query JFR Event output using jfr CLI:
// jdk.SafepointWait {
//   startTime = 14:02:01.102
//   duration = 42.8 ms
//   safepointId = 1042
//   waitThread = "ForkJoinPool-1-worker-4" (Carrier Thread)
// }

Key Takeaways

Virtual threads do not protect you from C2 loop optimizations that eliminate safepoint polls.
JDK 26 JFR events (jdk.SafepointWait) explicitly identify which worker thread delayed the VM operation.
Use -XX:+UseCountedLoopSafepoints when processing large in-memory primitive data structures under strict SLA targets.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Stop Letting Claude Code Hallucinate Your Modernization: Write OpenRewrite LST Recipes Instead

Machine coding Master — Mon, 10 Aug 2026 04:15:12 +0000

Stop Letting Claude Code Hallucinate Your Modernization: Write OpenRewrite LST Recipes Instead

Letting autonomous AI agents directly rewrite million-line Java monoliths is a dangerous game of Russian roulette with silent runtime bugs. The real way to execute large-scale JDK 26 upgrades is using Claude Code CLI to author deterministic OpenRewrite LST recipes—not blindly edit source files.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

Why Most Developers Get This Wrong

Yolo-prompting Claude Code CLI to edit hundreds of .java files directly, introducing non-existent API calls and broken imports.
Treating OpenRewrite Lossless Semantic Trees (LST) like naive regex text manipulation instead of type-attributed AST structures.
Relying on LLM self-correction loops to fix hallucinated method signatures instead of relying on the Java compiler.

The Right Way

Use Claude Code CLI to generate, unit-test, and refine type-safe OpenRewrite Java recipes, then let rewrite-maven-plugin execute them deterministically.

Prompt Claude Code to extend org.openrewrite.java.JavaVisitor targeting specific legacy patterns (e.g., Spring Boot 3+ or Jakarta EE migrations).
Validate recipe execution against OpenRewrite's type-attribution engine to guarantee zero semantic drift across your codebase.
Execute the generated recipe via mvn rewrite:run in a clean CI container for 100% reproducible diffs.
Isolate LLM non-determinism to the recipe authoring phase—keep your production target repo completely deterministic.

Show Me The Code (or Example)

Prompt Claude Code CLI to generate this exact imperatively-safe recipe structure:

public class MigrateToJDK26VirtualThreads extends Recipe {
    @Override
    public String getDisplayName() { return "Migrate Executors to Virtual Threads"; }

    @Override
    public TreeVisitor<?, ExecutionContext> getVisitor() {
        return new JavaIsoVisitor<ExecutionContext>() {
            private final MethodMatcher MATCHER = new MethodMatcher("java.util.concurrent.Executors newFixedThreadPool(int)");

            @Override
            public J.MethodInvocation visitMethodInvocation(J.MethodInvocation method, ExecutionContext ctx) {
                if (MATCHER.matches(method)) {
                    return JavaTemplate.builder("Executors.newVirtualThreadPerTaskExecutor()")
                        .build().apply(getCursor(), method.getCoordinates().replace());
                }
                return super.visitMethodInvocation(method, ctx);
            }
        };
    }
}

Key Takeaways

LLMs generate logic; deterministic AST engines transform code—never confuse the two responsibilities.
Generating OpenRewrite recipes via Claude Code gives you compiler-backed type safety across enterprise-scale Java migrations.
If an AI-driven refactor isn't backed by a Lossless Semantic Tree parser, it belongs nowhere near your production monolith.

Stop Infinite ReAct Loops: Deterministic Cycle Detection in Spring AI with Java 21 Record Patterns

Machine coding Master — Sun, 09 Aug 2026 04:01:46 +0000

Stop Infinite ReAct Loops: Deterministic Cycle Detection in Spring AI with Java 21 Record Patterns

Runaway ReAct agent loops are the single fastest way to blow through a enterprise LLM budget in a single deployment. If you rely on soft system prompt instructions or simple max-message limits to stop infinite agent execution, your production setup is a liability.

Why Most Developers Get This Wrong

Relying on hard iteration caps: Setting max-iterations=10 in your orchestrator just defers the bill spike without solving deterministic tool loops.
Naive string matching: Checking raw LLM text output misses cycles when tool arguments contain dynamic values like timestamps or ephemeral tracing IDs.
Prompt-level guardrails: Pleading with models ("do not execute the same tool twice") fails probabilistically under heavy context windows.

The Right Way

Catch execution cycles at the runtime level by pairing a custom Spring AI CallAroundAdvisor with Java 21 record patterns across a rolling sliding window.

Intercept at the Advisor boundary: Intercept AdvisedRequest payloads before Spring AI dispatches state back to your model provider.
Deconstruct tool calls with Record Patterns: Extract tool signatures and arguments cleanly using Java 21 pattern matching (case ToolCall(String name, Map args)).
Sliding Window Fingerprinting: Hash sanitized tool signatures over a 5-step rolling window to instantly catch $A \rightarrow B \rightarrow A$ cyclic tool execution.
Short-circuit execution: Throw a typed runtime exception immediately to break the loop before incurring another API token charge.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Show Me The Code

public record ToolCall(String name, Map<String, Object> args) {}

public class CycleDetectionAdvisor implements CallAroundAdvisor {
    private final SlidingWindowCache<Integer> window = new SlidingWindowCache<>(5);

    @Override
    public AdvisedResponse around(AdvisedRequest req, CallAroundAdvisorChain chain) {
        if (req.attributes().get("last_tool") instanceof ToolCall(String name, var args)) {
            int signatureHash = Objects.hash(name, sanitize(args));
            if (window.containsAndAdd(signatureHash)) {
                throw new AgentCycleDetectedException("Loop detected for tool: " + name);
            }
        }
        return chain.nextAround(req);
    }
}

Key Takeaways

Enforce guardrails in code, not prompts: LLMs are probabilistic, but cycle detection in your backend pipeline must be strictly deterministic.
Leverage Java 21 Record Patterns: Cleanly destruct agent state without messy reflection or verbose instance checks.
Fail fast at the framework edge: Catch tool looping inside Spring AI's CallAroundAdvisor before firing unnecessary LLM token calls.

Mastering the Producer-Consumer Pattern in Java LLD: The Restaurant Kitchen

Machine coding Master — Sat, 08 Aug 2026 03:51:50 +0000

Mastering the Producer-Consumer Pattern in Java LLD: The Restaurant Kitchen

The Producer-Consumer pattern is a staple in Java Machine Coding interviews because it tests your real-world concurrency control without breaking thread safety. Mastering it proves you can handle asynchronous thread handoffs without burning CPU cycles or risking deadlocks.

The Mistake Most Candidates Make

Writing custom lock logic using wait() and notifyAll() inside synchronized blocks, introducing subtle race conditions and spurious wakeup bugs.
Busy-waiting inside while(true) loops with non-thread-safe collections, thrashing the CPU while repeatedly checking queue sizes.
Neglecting backpressure control, leading to OutOfMemoryError when producers produce messages faster than consumers can process them.

The Right Approach

Core mental model: Chefs (producers) place dishes on a fixed-capacity kitchen pass counter (bounded buffer), while waiters (consumers) pick them up when ready.
Key entities: Order, Chef, Waiter, KitchenPass.
Why it beats the naive approach: java.util.concurrent.BlockingQueue encapsulates all thread coordination natively under the hood, completely removing the need for explicit boilerplate locking.

The Key Insight (Code)

public class KitchenPass {
    private final BlockingQueue<Order> pass = new ArrayBlockingQueue<>(10);

    public void prepareOrder(Order order) throws InterruptedException {
        // Blocks automatically if the pass is full (handles backpressure)
        pass.put(order);
    }

    public Order deliverOrder() throws InterruptedException {
        // Blocks automatically if the pass is empty (prevents CPU spinning)
        return pass.take();
    }
}

Key Takeaways

BlockingQueue completely decouples producers from consumers using internal reentrant locks and condition signals.
put() blocks producers when full, providing instant backpressure; take() blocks consumers when empty, preserving CPU performance.
Prefer standard java.util.concurrent primitives over manual thread orchestration during Machine Coding interviews.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Full working implementation with execution trace available at https://javalld.com/learn/producer-consumer