DEV Community: Machine coding Master

Stop Hand-Rolling AI Glue: Claude 4 MCP + Spring AI is the New Enterprise Standard

Machine coding Master — Sun, 26 Apr 2026 05:26:11 +0000

Stop Hand-Rolling AI Glue: Claude 4 MCP + Spring AI is the New Enterprise Standard

In 2026, if you are still building proprietary wrappers to connect LLMs to your microservices, you are creating technical debt that will haunt your team for years. The industry has consolidated around Claude 4 and the Model Context Protocol (MCP) because it finally brings the type safety and standardized discovery we’ve lacked in the "prompt engineering" era.

Why Most Developers Get This Wrong

Schema Drift: Treating LLM tools as loosely typed REST calls, leading to Claude 4 hallucinating parameter types and crashing your downstream services.
Over-Orchestration: Building complex "Agent Frameworks" from scratch instead of using Spring AI’s native MCP client to handle the JSON-RPC over SSE handshake.
Security Blindness: Exposing raw database access to the model instead of defining granular McpResource boundaries via the Java SDK.

The Right Way

The goal is to move from "LLM-as-a-chatbot" to "LLM-as-a-typed-runtime" by exposing your domain logic through a standardized MCP Server.

Use the spring-ai-mcp-boot-starter to automatically expose Spring beans as discoverable tools.
Enforce contract-first development by defining your tool inputs as Java Records—the MCP SDK uses these to generate the JSON-RPC schemas Claude 4 requires.
Implement McpResourceProvider for read-only data (like logs or docs) and reserve McpTool strictly for side-effect-heavy operations.
Standardize on Server-Sent Events (SSE) for the transport layer to bypass the overhead of persistent WebSockets in serverless environments.

Show Me The Code

This is how you define a type-safe bridge between Claude 4 and your enterprise inventory system using the 2026 Spring AI MCP SDK:

@Configuration
@EnableMcpServer(title = "Inventory-Service", version = "2.4.0")
public class McpEnterpriseConfig {

    @Bean
    public McpTool stockChecker(InventoryService service) {
        return McpTool.builder()
            .name("query_erp_stock")
            .description("Get real-time SKU availability from SAP/Oracle")
            .inputSchema(StockRequest.class) // Auto-generates JSON-RPC schema
            .handler(req -> service.fetch(req.skuId(), req.warehouseCode()))
            .build();
    }
}

// Claude 4 now sees a strictly typed 'query_erp_stock' tool via SSE
record StockRequest(String skuId, String warehouseCode) {}

Key Takeaways

Decoupling: MCP is the "JDBC for LLMs"—it separates your model logic from your data infrastructure.
Type Safety: Using Java Records with MCP ensures Claude 4 never sends a string where your service expects an integer.
Discovery: Claude 4 agents can now "introspect" your entire service capability at runtime, eliminating the need for manual prompt updates.

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

Java LLD: Designing a High-Concurrency Twitter Feed

Machine coding Master — Sat, 25 Apr 2026 05:00:32 +0000

Java LLD: Designing a High-Concurrency Twitter Feed

Designing a Twitter-style news feed is a staple of FAANG machine coding interviews. It forces you to demonstrate a deep understanding of read-vs-write trade-offs and thread-safe data structures in a high-scale environment.

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

The Mistake Most Candidates Make

The Pull Model Trap: Querying the database for all followed users' tweets and sorting them by timestamp on every single read request. This results in $O(N \log N)$ read latency, which kills performance as the social graph grows.
Ignoring Concurrency: Using standard collections like ArrayList or HashMap for feeds, leading to ConcurrentModificationException when one thread posts a tweet while another reads the feed.
Lack of Bound Checks: Failing to implement a sliding window or capacity limit for in-memory feeds, eventually leading to OutOfMemoryError as the system scales.

The Right Approach

Core Mental Model: Use a "Push-based" (Fan-out on Write) architecture where a tweet is delivered to every follower's pre-computed timeline at the moment it is posted.
Key Entities: User, Tweet, FeedService, SocialGraphService, and Timeline.
Why it beats the naive approach: It optimizes for the 99% read-heavy nature of social media by making feed retrieval a simple $O(1)$ memory access, shifting complexity to the asynchronous write path.

The Key Insight (Code)

To maintain a sorted, thread-safe feed that automatically discards old tweets, use ConcurrentSkipListMap. This allows concurrent access while keeping tweets ordered by timestamp.

public class FeedService {
    private final Map<Long, ConcurrentSkipListMap<Long, Tweet>> userFeeds = new ConcurrentHashMap<>();
    private static final int MAX_FEED_SIZE = 200;

    public void fanOut(long authorId, Tweet tweet) {
        Set<Long> followers = socialGraph.getFollowers(authorId);
        for (Long followerId : followers) {
            // Get or create the thread-safe sorted feed
            ConcurrentSkipListMap<Long, Tweet> feed = userFeeds
                .computeIfAbsent(followerId, k -> new ConcurrentSkipListMap<>(Comparator.reverseOrder()));

            feed.put(tweet.getTimestamp(), tweet);

            // Maintain sliding window
            if (feed.size() > MAX_FEED_SIZE) feed.pollLastEntry();
        }
    }
}

Key Takeaways

Fan-out on Write: Always optimize for the most frequent operation; in Twitter's case, viewing a timeline happens orders of magnitude more often than posting.
The Observer Pattern: Decouple the PostTweet logic from the FanOut logic to ensure that a slow feed update doesn't block the user's primary action.
Thread-Safety without Locking: Leverage java.util.concurrent structures like ConcurrentSkipListMap to handle high-frequency updates without the performance bottleneck of synchronized blocks.

Full working implementation with execution trace available at https://javalld.com/problems/twitter-feed

Claude 3.7 + JEP 480: Stop Building Fragile AI Agents with CompletableFuture

Machine coding Master — Fri, 24 Apr 2026 05:22:25 +0000

Claude 3.7 + JEP 480: Stop Building Fragile AI Agents with CompletableFuture

Claude 3.7 just dropped with superior reasoning and "Computer Use" capabilities, but your agentic workflow is only as strong as its orchestration layer. If you're still using CompletableFuture.allOf() to manage parallel tool calls, you're building a distributed system that fails silently and leaks resources.

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

Unbounded thread creation: Wrapping blocking Claude API calls in CachedThreadPools is a recipe for OOM errors when agentic loops spin out of control.
Orphaned tool executions: When one tool call fails (e.g., a timeout on a web search), its siblings keep running, wasting tokens and compute because there's no parent-child relationship.
Swallowed exceptions: Standard async patterns make it nearly impossible to propagate a specific ToolExecutionException back to the Claude context without losing the stack trace.

The Right Way

Use StructuredTaskScope (JEP 480) to treat a multi-tool execution block as a single unit of work that fails fast and cleans up after itself.

Deterministic Shutdown: Use StructuredTaskScope.ShutdownOnFailure() to ensure that if one tool call fails, all other pending tasks in that reasoning step are immediately cancelled.
Virtual Thread Integration: Map each Claude tool request to a Virtual Thread (JEP 444) to handle high-concurrency I/O without the memory overhead of platform threads.
Context Propagation: Ensure the anthropic-beta: computer-use-2024-10-22 headers and conversation state are scoped to the current task hierarchy.

Show Me The Code

This is how you orchestrate parallel tool calls for a Claude 3.7 agent using structured concurrency.

public List<ToolResponse> executeParallelTools(List<ToolCall> calls) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        List<Subtask<ToolResponse>> tasks = calls.stream()
            .map(call -> scope.fork(() -> toolRegistry.execute(call)))
            .toList();

        scope.join();           // Wait for all tool calls
        scope.throwIfFailed();  // Propagate the first error encountered

        return tasks.stream().map(Subtask::get).toList();
    }
}

Key Takeaways

JEP 480 is the "Try-With-Resources" for threads: It turns asynchronous tool calls into a synchronous-looking, deterministic control flow.
Claude 3.7's reasoning is expensive: Don't let a stray thread or a zombie API call burn your budget; use ShutdownOnFailure to kill sub-tasks the moment one fails.
Fail-fast is the only strategy: For production agents, if one tool dies, the whole reasoning step should pivot or retry—never allow partial, inconsistent state.

Your Virtual Threads Are Leaking: Why ScopedValue is the Only Way Forward

Machine coding Master — Thu, 23 Apr 2026 21:13:57 +0000

Your Virtual Threads Are Leaking: Why ScopedValue is the Only Way Forward.

If you're spinning up millions of Virtual Threads but still clinging to ThreadLocal, you're building a memory bomb. Java 21 changed the game, and if you haven't migrated to ScopedValue yet, you're missing the actual point of lightweight concurrency.

Why Most Developers Get This Wrong

The Scalability Trap: Treating Virtual Threads like Platform Threads. Thinking millions of ThreadLocal maps won't wreck your heap is a rookie mistake; the per-thread overhead adds up fast when you scale to 100k+ concurrent tasks.
The Mutability Nightmare: Using ThreadLocal.set() creates unpredictable side effects in deep call stacks. In a world of massive concurrency, mutable global state is a debugging death sentence.
Manual Cleanup Failures: Relying on try-finally to .remove() locals. It inevitably fails during unhandled exceptions or complex async handoffs, leading to "ghost" data bleeding between requests.

The Right Way

Shift from long-lived, mutable thread-bound state to scoped, immutable context propagation.

Use ScopedValue.where(...) to define strict, readable boundaries for your data (like Tenant IDs or User principals).
Embrace Structured Concurrency: use StructuredTaskScope to ensure context propagates automatically and safely to child threads.
Treat context as strictly immutable; if you need to change a value, you re-bind it in a nested scope rather than mutating the current one.
Optimize for memory: ScopedValue is designed to be lightweight, often stored in a single internal array rather than a complex hash map.

Show Me The Code

private final static ScopedValue<String> TENANT_ID = ScopedValue.newInstance();

public void serveRequest(String tenant, Runnable logic) {
    // Context is bound to this scope and its children only
    ScopedValue.where(TENANT_ID, tenant).run(() -> {
        performBusinessLogic();
    });
    // Outside this block, TENANT_ID is automatically cleared
}

void performBusinessLogic() {
    // O(1) access, no risk of memory leaks, completely immutable
    String currentTenant = TENANT_ID.get(); 
    System.out.println("Working for: " + currentTenant);
}

Key Takeaways

Memory Efficiency: ScopedValue eliminates the heavy ThreadLocalMap overhead, making it the only viable choice for high-density Virtual Thread architectures.
Safety by Default: Immutability isn't a limitation; it's a feature that prevents "spooky action at a distance" across your call stack.
Structured Inheritance: Unlike InheritableThreadLocal, which performs expensive data copying, ScopedValue shares data efficiently with child threads within a StructuredTaskScope.

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

Java Machine Coding: Building a Dependency Resolver with Topological Sort

Machine coding Master — Thu, 23 Apr 2026 20:59:09 +0000

Java Machine Coding: Building a Dependency Resolver with Topological Sort

Dependency management is the backbone of build tools like Maven or Gradle and a high-signal problem in senior-level machine coding interviews. If you cannot correctly order task execution or detect circular dependencies, your system will fail at scale.

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

The Mistake Most Candidates Make

Naive Recursion: Using simple DFS without state tracking, which leads to redundant computations or infinite loops in circular graphs.
Ignoring In-Degrees: Attempting to "find" the next task by iterating over the entire list repeatedly ($O(N^2)$), rather than tracking which tasks are ready.
Coupling Logic: Mixing the task execution logic directly into the graph traversal code, making the system hard to test and extend.

The Right Approach

Core Mental Model: Represent the system as a Directed Acyclic Graph (DAG) and use Kahn’s Algorithm (BFS) to resolve nodes with zero incoming edges first.
Key Entities: Task, DependencyGraph, DependencyResolver.
Why it beats the naive approach: Kahn’s Algorithm provides $O(V + E)$ time complexity and offers a "free" way to detect cycles—if your output list is smaller than your input, you have a circular dependency.

The Key Insight (Code)

The heart of the resolver is maintaining the inDegree map. When a task's in-degree hits zero, it is ready for execution.

public List<String> resolve(Map<String, List<String>> adj, Map<String, Integer> inDegree) {
    Queue<String> queue = new LinkedList<>();
    inDegree.forEach((node, degree) -> { if (degree == 0) queue.add(node); });

    List<String> order = new ArrayList<>();
    while (!queue.isEmpty()) {
        String current = queue.poll();
        order.add(current);
        for (String neighbor : adj.getOrDefault(current, new ArrayList<>())) {
            inDegree.put(neighbor, inDegree.get(neighbor) - 1);
            if (inDegree.get(neighbor) == 0) queue.add(neighbor);
        }
    }
    if (order.size() != inDegree.size()) throw new CircularDependencyException();
    return order;
}

Key Takeaways

In-degree Tracking: This is the most efficient way to identify "ready-to-run" tasks without re-scanning the graph.
Cycle Detection: Always validate that the final sorted list size equals the total number of nodes to catch hidden circularities.
Separation of Concerns: Keep your graph representation (nodes/edges) distinct from the execution engine to allow for future features like parallel execution.

Full working implementation with execution trace available at https://javalld.com/problems/dependency-builder

Java LLD: Designing a Kafka-Like Message Queue for Machine Coding Interviews

Machine coding Master — Thu, 23 Apr 2026 20:29:05 +0000

Java LLD: Designing a Kafka-Like Message Queue for Machine Coding Interviews

Designing a high-performance message queue is a frequent requirement in senior-level machine coding rounds. It tests your ability to balance thread safety with decoupled architecture while managing stateful consumer progress.

The mistake most candidates make

Using a standard java.util.Queue that removes elements upon polling, which prevents multiple consumer groups from reading the same data.
Coupling the Producer directly to the Consumer logic, violating the Pub-Sub principle and making the system brittle to scale.
Failing to implement independent offset management, leading to data loss or duplicate processing when one consumer lags.

The right approach

Core mental model: An immutable, append-only log where messages are persisted per topic, allowing consumers to track their own progress independently.
Key entities: Topic, Message, Subscriber, ConsumerGroup, OffsetManager.
Why it wins: It enables "replayability" and allows multiple heterogeneous systems to consume the same stream at different speeds without interference.

Implementation Insight: The Thread-Safe Log

public class Topic {
    private final List<Message> messages = new ArrayList<>();
    private final ReentrantLock lock = new ReentrantLock();

    public void addMessage(Message message) {
        lock.lock();
        try {
            messages.add(message);
        } finally {
            lock.unlock();
        }
    }

    public List<Message> getMessagesFrom(int offset) {
        return (offset >= messages.size()) ? List.of() : messages.subList(offset, messages.size());
    }
}

Key takeaways

Decouple producers and consumers by using an append-only log structure instead of a destructive queue.
Use ReentrantLock to ensure atomic appends to the message log in a multi-threaded producer environment.
Manage consumer state via independent offsets, allowing each ConsumerGroup to process messages at its own pace.

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

Java LLD Interview Prep

Machine coding Master — Thu, 23 Apr 2026 20:20:09 +0000

Java LLD: Designing a Scalable Job Scheduler Without Busy Polling

In my time at companies like Apple and Amazon, the "Job Scheduler" was a go-to interview question for senior roles. It isn't just about whether you can write a loop; it’s a litmus test for your understanding of resource management, thread safety, and low-level synchronization primitives. If you can't explain how to wake up a thread at the exact millisecond a job is due, you aren't passing the bar.

Why This Topic Matters

Designing a job scheduler is a foundational Low-Level Design (LLD) problem because it mirrors real-world systems like Crontab, Quartz, or the internal task executors used in microservices. In an interview, you aren't being asked to use ScheduledExecutorService; you are being asked to build it. The interviewer is looking for precision, efficiency, and a deep grasp of Java’s java.util.concurrent package.

The Mistake Most Candidates Make

The most common pitfall is "Busy Polling." I’ve seen countless candidates implement a while(true) loop that calls Thread.sleep(1000) and checks a queue for pending tasks.

This approach is flawed for two reasons:

Latency: If a job is scheduled for T+50ms and your thread just started a 1000ms sleep, the job will be 950ms late.
CPU Waste: If the queue is empty, the thread keeps waking up unnecessarily, consuming CPU cycles and draining battery/resources for no reason.

Experienced engineers know that the goal is to have the scheduler thread sleep for the exact duration until the next task is due, or until a new, higher-priority task is added.

The Right Approach: The Mental Model

To build a production-grade scheduler, you need to combine the Command Pattern with a Priority Queue and fine-grained synchronization.

Key Entities

Job: A wrapper around a Runnable that includes an executionTime (epoch timestamp).
Scheduler: A Singleton that manages the lifecycle of the background worker.
JobStore: A PriorityQueue (min-heap) that keeps the job with the earliest execution time at the head.
WorkerThread: The consumer thread that waits for jobs to become "due."

Why This Wins

Instead of generic sleeping, we use ReentrantLock and its associated Condition object. This allows us to implement a "wait-with-timeout" strategy. If a new job arrives that is scheduled earlier than the current head of the queue, we can signal the worker thread to wake up, recalculate its wait time, and go back to sleep—or execute the new job immediately.

The Core Insight: Smart Waiting

The magic happens in the worker's execution loop. We don't just wait; we wait conditionally. We use Condition.await(delay) to put the thread into a timed-waiting state. This is more efficient than Thread.sleep because it can be interrupted by a signal() call when a new job is pushed.

public void run() {
    while (running) {
        lock.lock();
        try {
            while (jobQueue.isEmpty()) {
                newJobCondition.await(); // Wait indefinitely for the first job
            }

            long currentTime = System.currentTimeMillis();
            Job nextJob = jobQueue.peek();
            long delay = nextJob.getExecutionTime() - currentTime;

            if (delay <= 0) {
                executorService.submit(jobQueue.poll()); // Execute due job
            } else {
                // Wait until the job is due OR a new job is added
                newJobCondition.await(delay, TimeUnit.MILLISECONDS);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock();
        }
    }
}

Concurrency Angle: Thread Safety and Atomicity

When designing this, you must account for the Producer-Consumer race condition. While the worker thread is checking the peek() of the queue, a producer thread might be calling addJob().

If you use a standard PriorityQueue, it is not thread-safe. Even if you use a PriorityBlockingQueue, it doesn't solve the "wait-until-due" logic on its own. You need the ReentrantLock to ensure that the process of checking the time and deciding to wait is atomic.