Markus Eisele’s Post

Refactoring legacy Java used to mean months of risk and guesswork. AI is changing that. At Code Remix Summit, Vinicius Senger and Jonathan Vogel from Amazon Web Services (AWS) walk through a practical end-to-end workflow for upgrading legacy Java, modernizing architectures, and connecting code changes to measurable production performance using AI, Java Flight Recorder, and custom Embabel agents. Don't miss this! Get your ticket ⤵️ https://lnkd.in/g5r2MUSJ #Java #SpringBoot #CodeRemixSummit #JavaModernization #DeveloperProductivity

Why the combination of Spring AI and MCP is the new standard for Java-based AI infrastructure. Spring AI makes it remarkably simple to implement MCP, effectively providing a USB-C port for your Java backend logic. Instead of manually hard-coding function definitions for every integration, we can now use a standardized protocol where services describe their own capabilities. The Plug-and-Play advantage for Java teams: ✅ Runtime Discovery: You don't have to wire every tool manually. When you connect an MCP server, your Spring AI application can discover its capabilities dynamically. ✅ Architectural Decoupling: Keep your business logic in specialized MCP servers. Your main Spring Boot app stays clean and focused on the core orchestration. ✅ Protocol-Based Integration: Define your tools once. By using a standard protocol, you reduce the need for custom, brittle integration code between your Java ecosystem and the AI models. The shift from manual wiring to standardized connection is what makes AI truly production-ready in the enterprise. Biased? Maybe. But in my Spring AI workshops, it’s clear how much complexity is removed when you move from custom code to the pure simplicity of a standardized MCP architecture. (Links to the previous posts in this series can be found in the first comment.) #SpringAI #MCP #Java #SpringBoot #SpringAIEntersTheChat #EnterpriseArchitecture

Christian Tzolov introduces the Spring AI roadmap at Spring I/O keynote: - 2.0 May 2026 : Spring Boot 4 baseline, Jackson 3, null safety, API refinements, MCP updates, focus on quality and consistency - 2.1 November 2026 : dedicated agentic API and annotations, durable workflow, sessions - 3.0 May 2027 : unified Virtual Thread friendly stack (no more blocking versus reactive dilemma) #spring #java #springio26

🚀 Backend Learning | Event-Driven Architecture in Modern Systems While working on backend systems, I recently explored how systems communicate efficiently using event-driven architecture. 🔹 The Problem: • Tight coupling between services • Slow response when handling multiple dependent operations • Difficult to scale synchronous systems 🔹 What I Learned: • Event-Driven Architecture (EDA) allows services to communicate via events • Producers publish events, consumers react asynchronously • Tools like Kafka / RabbitMQ enable event streaming 🔹 Key Insights: • Improves scalability and flexibility • Reduces coupling between services • Enables asynchronous processing 🔹 Outcome: • Faster and more scalable systems • Better handling of high-volume events • Improved system decoupling Modern systems are not just request-response — they are event-driven. 🚀 #Java #SpringBoot #SystemDesign #BackendDevelopment #Microservices #Kafka #EventDriven #LearningInPublic

Imagine transforming a raw PDF requirements document into fully reviewed, tested, and deployed Java code without a single byte of data ever leaving your machine. 🔒 Meet CodeForgeAI: a 5-agent multi-LLM pipeline built with Spring Boot 4.0.x and Spring AI 2.0.0-M3 that runs 100% on-premise. In an era where cloud-hosted AI tools raise massive red flags for enterprise security, we wanted to see if a developer laptop could handle the entire lifecycle—from requirements to Jira stories to production-quality code—using only local, open-weight models via Ollama. The "Team" Under the Hood: We didn't just build a script; we orchestrated a specialized workforce of 5 AI agents: - Business Analyst: Turns PDFs into structured user stories. - Code Generator: Drafts the implementation. - Code Reviewer: Performs a two-layer (deterministic + LLM) quality check. - Test Generator: Writes JUnit 5 tests. - Test Executor: Compiles and runs everything via Maven. The Real-World Struggles Running multiple LLMs locally on an Intel Core Ultra 7 (CPU-only!) wasn't easy. We hit major roadblocks that most "Hello World" AI tutorials ignore: The Context Window Wall: How do you pass a full codebase to a 7B model without blowing past 16k tokens? We solved this with a "Signatures-Index" trick. The Reload Lag: Why was every agent-to-agent handoff losing 30 seconds? It turns out uniforming num_ctx was the secret breakthrough. Truncated Output: What happens when your LLM stops mid-method? We built auto-repair logic to count braces and close the deficit. Why This Matters We’ve documented the entire architecture, from the PGVector RAG implementation to the real-time Vaadin UI with server push. Whether you are looking to secure your proprietary codebase or just want to see how far local LLMs can be pushed, there is a wealth of "hard-learned" lessons in this project. Ready to see the full tech stack and the "breakthrough" configurations that made it work? Check out the deep dive on the blog and the full source code on GitHub. 👇 https://lnkd.in/gN-mGDk6 #Java #SpringAI #LocalLLM #GenerativeAI #SoftwareEngineering #DataPrivacy #SpringBoot #Ollama

🚀 Building a Custom AI Agent for Spring 3.x → 4.x Migration Modernizing legacy applications is never easy—especially when dealing with older Spring frameworks. Recently, I explored building a custom AI-powered agent to simplify the Spring 3.x to 4.x upliftment process. 🔍 What does this agent do? - Scans legacy codebases (Java + XML configurations) - Detects deprecated patterns and outdated configurations - Suggests migration strategies (XML → Java Config, annotations, etc.) - Generates upgraded code snippets using AI - Helps reduce manual effort and migration risks ⚙️ Tech Stack Used - Java + Spring Boot - LangChain4j for agent orchestration - OpenAI API for intelligent code transformation 🧠 Key Insight A successful migration agent is not just AI-driven. It’s a combination of: - Rule-based static analysis (for accuracy) - AI-powered suggestions (for flexibility) ⚡ Impact - Faster migration cycles - Reduced human error - Better consistency across large codebases This approach can be extended further to Spring Boot upgrades, microservices modernization, and even full-stack transformations. #Java #SpringFramework #AI #GenerativeAI #SoftwareEngineering #Modernization #TechInnovation

One thing I keep seeing with AI-assisted development: teams put real effort into good agent instructions, and then manage them with copy-paste. That works for one repo. It breaks the moment you have five. I wrote a new hands-on tutorial about using SkillsJars to package reusable Quarkus-focused IBM Bob skills as versioned Maven artifacts, publish them, and consume them across projects. The idea is simple: if agent knowledge matters, it should be managed with the same discipline as any other dependency. In the article, I walk through: - authoring Quarkus-focused SKILL.md files - packaging them into a JAR - publishing and consuming them via Maven - extracting them into .bob/skills for real project use I also call out the security angle, because agent skills are useful, but they are not harmless. https://lnkd.in/dqR2MpzE #Java #Quarkus #Maven #ArtificialIntelligence #DeveloperTools #SoftwareEngineering #IBMBob #AgenticAI

Why your 16GB Heap is pausing your AI Agents (and the 2026 fix). ⏱️🗑️ If you are running a modern Spring Boot application, you are likely using the default G1 Garbage Collector. For 90% of microservices, G1 is fantastic. It balances throughput and latency nicely. But what happens when you enter the top 10%? In my Travel Agent RAG system, a single user query might trigger parallel calls to Ollama, parse megabytes of JSON responses, and map thousands of vector embeddings. This creates massive "Object Churn" in the young generation of the heap. Under this kind of load, G1 GC eventually has to clean up. When it does, it triggers a "Stop-The-World" pause. Your application completely freezes. Even a 200ms pause during an LLM streaming response feels like a massive lag spike to the user. The Fix: Generational ZGC. Introduced as a production-ready feature in Java 21, Generational ZGC is designed to give you sub-millisecond pause times, regardless of whether your heap is 1GB or 16 Terabytes. It does the heavy lifting of garbage collection concurrently alongside your application threads. The 2026 JVM Flags: Bash # ❌ THE DEFAULT (Prone to latency spikes under heavy AI load) java -XX:+UseG1GC -jar travel-agent.jar # ✅ THE HIGH-SCALE FIX (Sub-millisecond pauses) java -XX:+UseZGC -XX:+ZGenerational -jar travel-agent.jar Why this is a Senior Architectural Move: Predictable p99 Latency: Your API response times become entirely predictable because the JVM never freezes for more than a fraction of a millisecond. No Tuning Required: Unlike older collectors where you had to meticulously tune generation sizes and pause targets, ZGC is designed to be auto-tuning. You set the max heap size, and it handles the rest. If you are building Agentic workflows or high-throughput data pipelines, upgrading your GC is the highest ROI change you can make without touching a single line of business logic. Are you still riding with G1 GC, or have you benchmarked Generational ZGC in your production environment? Let’s swap metrics below. 👇 #Java #JVM #GarbageCollection #BackendEngineering #SystemDesign #SoftwareArchitecture #HighScale #PerformanceTuning

🚀 Day 4 – JVM & Memory Management (Connecting the Dots with Concurrency) Hi everyone 👋 After exploring multithreading and how multiple tasks execute concurrently, I wanted to understand how memory is managed behind the scenes — which led me to the JVM. 📌 What I explored: 🔹 JVM Architecture (high-level) - Class Loader → loads bytecode - Runtime Memory → Heap, Stack, Metaspace - Execution Engine → executes code 🔹 Heap vs Stack (in context of threads) - Heap → shared across all threads (objects) - Stack → thread-specific (method calls, local variables) 🔹 Garbage Collection (GC) - Automatically removes unused objects - Helps manage memory efficiently - Impacts performance if not handled properly 🔹 Memory + Concurrency Connection - Multiple threads share heap → risk of data inconsistency - High object creation → increased GC activity - Poor memory handling → performance bottlenecks 📌 Why this matters in real systems: In high-scale systems (including AI-driven applications), 👉 Multiple threads process requests simultaneously 👉 Large amounts of data are created and processed 💡 Example: An AI-based backend handling multiple requests: - Each request creates objects (responses, data processing) - All objects go to heap (shared memory) - More load → more memory usage → more GC cycles 👉 If not optimized, this can lead to latency spikes or memory issues 📌 Key Takeaway: Understanding JVM and memory management is essential to write efficient, scalable, and production-ready backend code. 📌 Question: 👉 What happens in the JVM when multiple threads try to access and modify the same object in heap memory? #Day4 #Java #JVM #MemoryManagement #Concurrency #BackendDevelopment #SystemDesign #AI #LearningInPublic

🚀 Clean architectures don’t fail in diagrams. They fail in production. So I built a production-grade microservices architecture that focuses on what actually matters: flow, failure handling, and system resilience under real-world conditions 👇 📊 Inside the system: • API Gateway → JWT validation, routing, rate limiting • Sync calls → REST / Feign between services • Async events → Kafka (order.created → payment → notification) • Circuit Breaker → isolates failures, prevents cascading impact • Retry + DLQ → guarantees eventual processing • Idempotency → ensures exactly-once payment behavior • Service Discovery + Config Server → dynamic, decoupled infrastructure • Observability → logs, metrics, tracing • Distributed tracing via Zipkin / Jaeger 🔁 Real execution flow: User → API Gateway → Order Service → Event published → Payment Service → Notification Service → Response ⚠️ Engineering truth: Failures are not edge cases. They are part of the normal operating conditions. Systems that scale are not the ones that avoid failure— but the ones that are designed to handle it gracefully. This is closer to how real backend systems are built and operated. #Microservices #SystemDesign #Java #SpringBoot #Kafka #BackendEngineering #SoftwareArchitecture