标签：#spring

Understanding Java's Virtual Threads: Lightweight Concurrency in Action Java 21 introduced virtual threads as a stable feature (JEP 444), fundamentally changing how we approach concurrency on the JVM. In this post, we'll explore what virtual threads are, why they matter, and how to use them effectively. The Problem with Platform Threads Traditional Java threads—now called platform threads —are thin wrappers around operating system threads. Each one consumes roughly 1MB of stack memory and involves the OS scheduler for context switching. This makes them expensive: java // Creating thousands of platform threads is costly for (int i = 0; i < 10_000; i++) { new Thread(() -> { // blocking I/O ties up an OS thread processRequest(); }).start(); } In high-throughput server applications, the classic "thread-per-request" model hits a ceiling because you simply cannot create enough OS threads. Enter Virtual Threads Virtual threads are managed by the JVM rather than the OS. Many virtual threads run on a small pool of carrier platform threads. When a virtual thread blocks (e.g., on I/O), the JVM detaches it from its carrier, freeing that carrier to run other virtual threads. java // Creating a million virtual threads is perfectly fine try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { IntStream.range(0, 1_000_000).forEach(i -> { executor.submit(() -> { Thread.sleep(Duration.ofSeconds(1)); return i; }); }); } Key Benefits Cheap creation : Virtual threads start with a tiny stack that grows on demand. Familiar model : You write straightforward blocking code—no callbacks or reactive chains. Better scalability : Throughput is limited by resources, not thread count. Using Virtual Threads in Spring Boot As of Spring Boot 3.2, enabling virtual threads is a one-line configuration change: properties spring.threads.virtual.enabled=true This makes Tomcat handle each request on a virtual thread, allowing your application to serve many concurrent blocking requests without exha

You open a new Spring Boot project and you create a DTO, then an entity, and you’re staring at getters, setters, constructors, equals() , hashCode() , toString() . Someone on the team suggests to put lombok’s @Data , or “just slap @Builder on it, it’ll be cleaner.” Forty lines become five and it looks great in the PR. Then it hits a real codebase, OpenAPI generation doesn't behave the way the build expects. Hibernate meets an auto-generated equals() and gets confused about identity. Something throws through a generated builder hierarchy at 2 AM, and the method you need to inspect doesn't exist in any file you can open. Eleven years into enterprise Java, my rule is simple: Lombok doesn't touch core application behavior. Not because writing a getter is interesting - it isn't, but because the handful of lines it saves rarely covers the compiler magic, tooling friction, and debugging problems it adds to something that has to survive for years after you've moved on to another project. "It just removes boilerplate" Worth asking what's actually being removed, though. A getter is part of your public API. A setter is a mutation point someone decided to expose. A constructor defines what states an object is allowed to enter. equals() and hashCode() define identity. toString() is what shows up in your logs when things go wrong at 3 AM. Write those by hand and they live in the source - visible, searchable, debuggable, owned by whoever's reading the file. Generate them with Lombok and the behavior is still there, it's just moved somewhere you can't see it without a separate step. The annotation most people reach for first time is @Data : @Data @Entity public class CustomerEntity { @Id @GeneratedValue private Long id ; private String email ; @OneToMany ( mappedBy = "customer" ) private List < OrderEntity > orders ; } One line and you get getters, setters, toString() , equals() , hashCode() across every field. For a JPA entity that's already a problem before you've written any bus

Last week I changed a system prompt based on a feeling. It was the first prompt change after the evaluation harness from Part 8 went live, and I was completely sure about it. The target was the markdown table. Part 8's first nightly run caught the agent answering price comparisons with a markdown table that renders broken in the chat frontend. The fix looked obvious: add one line to the system prompt demanding plain text. I checked six conversations by hand. All six looked better. I was ready to ship it to production. Then I ran the comparison the way Part 8 promised: the same 40 cases, the same judge, two prompts. The old prompt won. Not by a little. It won 18 pairs, lost 10, and tied 12, and the judge's rationales made the reason visible. The plain-text line had also made the agent terse, and terse answers dropped the order summary that customers actually need. My confidence was a sample size of one. The dataset was the jury. This part is about the pattern that settled that argument: pairwise comparison, the LLM-as-a-judge pattern for A/B testing prompts and tool descriptions before they reach production. It is the harness from Part 8, upgraded to answer "which version is better?" instead of "is this version good?" The Problem With Ship-by-Feeling Every prompt edit is an experiment with one sample. You notice one conversation where the agent is verbose, you add "be concise", and the change ships because that one conversation got better. The dataset from Part 8 makes the agent measurable, but a nightly score cannot tell you whether a change helped. One night is noise, three nights is a signal, and by the time you have three nights of data you have already shipped the change to every user. The variable itself is the problem. A system prompt and a tool description are the two things in an agent you cannot unit test. Part 6 proved the code is bug-free. Part 8 proved the answers are good on a fixed dataset. Neither says anything about whether your new wording is better

You put a lot of work into authentication. A gateway validates the Keycloak JWT, maps realm roles to authorities, checks that the caller is allowed. By the time a request reaches your service, you know exactly who is calling. Then the request crosses into async land, and all of that evaporates. This is the story of the point where identity quietly disappears in an event-driven system, why the dead-letter queue is the worst possible place for it to disappear, and how I made the acting user as durable and replay-safe as the event itself. The flow everyone believes is fine The platform is a set of Spring Boot services: an API gateway in front, a user-service on MySQL, a notification-service on PostgreSQL, and Kafka carrying events between them. A user is created, an event is published, a notification is sent. Authentication is handled at the edge. The gateway is an OAuth2 Resource Server; it validates the token once and propagates the caller's identity downstream as headers: // api-gateway — IdentityPropagationFilter (@Order(2), after security) IdentityContext identity = identityContextExtractor . extract ( jwt ); // Always set all three headers (empty when absent) to mask any spoofed values. enrichedRequest . putHeader ( IdentityHeaders . USER_NAME , nullToEmpty ( identity . username ())); enrichedRequest . putHeader ( IdentityHeaders . USER_EMAIL , nullToEmpty ( identity . email ())); enrichedRequest . putHeader ( IdentityHeaders . USER_ROLES , identity . rolesAsString ( DELIM )); One detail here matters more than it looks. The headers are always overwritten , even when a claim is absent. If a client tries to inject X-User-Name: admin on the inbound request, the gateway stomps it with the validated value (or empty). Downstream trust in those headers is only safe because the perimeter guarantees they cannot be forged. Miss that, and you've built an impersonation API. So far, so good. The synchronous hop carries identity. The problem starts one line later. The hidden f

You attach the OpenTelemetry Java agent, point it at a collector, and within minutes Grafana is drawing a service map you never drew. A box for each service, arrows between them, latency on every edge. It feels like magic, and — more dangerously — it feels complete . "The agent traces everything" is the sentence repeated in every onboarding doc. This is the story of the moment that sentence stopped being true on my platform, why I'm glad it did, and the difference between a system that is working and a system you can actually see . The flow everyone trusts The platform is an event-driven set of Spring Boot services: an API gateway in front, a user-service backed by MySQL, a notification-service backed by PostgreSQL, and Kafka carrying events between them. A user is created, an event is published, a notification is sent. I didn't want to draw that topology. A hand-drawn architecture diagram is documentation that drifts — true the day you commit it, slightly wrong a month later, actively misleading after a quarter. I wanted the dependency graph generated from live traffic , so it would always reflect what the system actually does. Grafana Tempo does exactly this. Its service-graphs processor reads matched client/server span pairs out of trace data and emits a metric — traces_service_graph_request_total — that Grafana renders as a node graph. No edge is ever wired by hand. The topology is derived, continuously, from real spans. The edge that wasn't there I generated the graph and the synchronous edges lit up immediately: api-gateway → user-service user-service → MySQL notification-service → PostgreSQL Then I looked for the one edge I actually cared about — user-service → notification-service , the asynchronous hop over Kafka. It wasn't there. The naive conclusion (and why it's wrong) The tempting read is immediate and obvious: the async hop is broken. The event isn't getting across. Go debug the consumer. So I checked. And the consumer was completely fine. notification

Last week I ran a demo of the agent for a colleague who was deciding whether to bet a feature on it. The approval gate from Part 7 worked exactly as designed. The agent searched, added to cart, asked for the address, and stopped at the confirmation link. My colleague nodded and asked one question: "OK, but is it actually good?" I did not have an answer. I had 31 passing tests from Part 6, which prove the agent is bug-free. I had a state machine, which proves it cannot place an order without a human. Neither of those proves the agent answers customers well. A bug-free agent can still tell a customer the shop ships within two days when the shipping partner takes five. No unit test catches that, because no unit test reads the answer. That is the gap this part closes. Part 7 ended with a promise: the next part would build an evaluation harness, so "is it good" stops being a feeling and becomes a score. This is that part. I built an LLM-as-a-judge harness for the same e-commerce agent as Parts 1 through 7: same nine tools, same supervisor, same memory. It runs 40 real conversations from production logs against five metrics every night and prints a score for each one. The first run was uncomfortable, and that is exactly why it exists. I am a Senior Software Engineer II at BS23 in Dhaka, and I have been building production AI agents with Spring Boot and Spring AI for over a year. Everything below is the harness as I actually run it. The Difference Between Tested and Good Part 6 tested the agent without an LLM: 31 tests, zero model calls, asserting on tool calls, services, and the order state machine. That suite answers "did the agent call the right tool, in the right order, with the right arguments?" It cannot answer "was the answer right?" because you cannot write an assertion for an LLM's wording. Evaluation is a different layer. You cannot assert on the answer, but you can judge it, and you can use an LLM to do the judging. Spring AI documents this pattern in its LLM-as

🚀 Building a REST API with Java Spring Boot: A Practical Beginner’s Guide If you're coming from Java and want to move into backend development, Spring Boot is one of the best frameworks to learn. It removes a lot of the boilerplate traditionally associated with Spring and makes it surprisingly easy to build production-ready REST APIs. In this article, we'll build a simple Blog REST API using: ☕ Java 🌱 Spring Boot 🌐 Spring Web 🗄️ Spring Data JPA 🐘 PostgreSQL 📦 Maven 🧪 Postman By the end, we'll have an API that can: Create a blog post Get all blog posts Get a post by ID Update a post Delete a post 1. What is Spring Boot? Spring Boot is a framework built on top of the Spring Framework that makes it easier to create Java applications. Without Spring Boot, you often need to configure many things manually. Spring Boot gives us: Auto-configuration Embedded servers Starter dependencies Production-ready features Easy REST API development A simple Spring Boot application can be started with: @SpringBootApplication public class BlogApplication { public static void main ( String [] args ) { SpringApplication . run ( BlogApplication . class , args ); } } That's enough to start our application. 2. Create the Spring Boot Project The easiest way to create a Spring Boot project is through Spring Initializr . Choose: Project: Maven Language: Java Spring Boot: Latest stable version Packaging: Jar Java: 17+ Add these dependencies: Spring Web Spring Data JPA PostgreSQL Driver Validation Lombok Your project structure will look something like: src └── main └── java └── com.example.blog ├── BlogApplication.java ├── controller ├── service ├── repository ├── entity └── dto This separation will become important as our application grows. 3. Create the Blog Entity Let's create a simple BlogPost entity. @Entity @Table ( name = "blog_posts" ) public class BlogPost { @Id @GeneratedValue ( strategy = GenerationType . IDENTITY ) private Long id ; @NotBlank private String title ; @NotBlank @Column (

Production-Grade Logging in Spring Boot: A Complete Guide to Logging Levels, Files, JSON Logs, Correlation IDs, and Best Practices Logging is one of the most important parts of a production backend system. When everything works, you may not think much about logs. But when production starts returning 500 errors at 2 AM, a customer reports that an API is failing, or a payment request behaves unexpectedly, logs become one of your most important debugging tools. Poor logging makes production debugging painful. Good logging helps you answer: What happened? When did it happen? Which user triggered it? Which request caused it? Which service handled it? How long did it take? What failed? Why did it fail? What should we investigate next? In this article, we will build a production-grade logging strategy for a Java Spring Boot application . 1. What Does Production-Grade Logging Mean? Production-grade logging is not simply: log . info ( "User created" ); Production logging should be: Structured Searchable Consistent Secure Configurable Environment-aware Correlated across requests Useful during debugging Suitable for monitoring and alerting A good logging architecture might look like this: Spring Boot Application | v Logback | +---- application.log | +---- error.log | +---- audit.log | +---- access.log | v Log Aggregation | +---- ELK +---- Grafana Loki +---- CloudWatch +---- Datadog +---- Splunk The goal is not to log everything. The goal is to log the right information at the right level . 2. Understanding Log Levels Spring Boot uses SLF4J as the logging abstraction and commonly uses Logback as the underlying logging implementation. The most common log levels are: TRACE DEBUG INFO WARN ERROR The order represents increasing severity. TRACE TRACE is the most detailed logging level. Example: log . trace ( "Entering calculateInvoice() with customerId={}" , customerId ); Use TRACE for very detailed diagnostic information. Usually: Production: OFF Development: Sometimes ON Debugging

Every new SaaS seems to embed ChatGPT these days. Most AI support solutions rely on third-party platforms, monthly subscriptions, and vendor lock-in. While they're great products, I wanted something different. I wanted complete ownership. I wanted to deploy everything on my own server, use my own OpenAI API key, customize every part of the experience, and embed the widget into any website with a single script tag. So I built my own self-hosted AI support widget using Spring Boot and Vanilla JavaScript. Why I Built It When building small products and websites, I realized that customer support quickly becomes a problem. Users have questions about pricing, features, returns, or simply get stuck. Most developers solve this by integrating services like Intercom, Crisp, or Tidio. Those platforms are excellent, but they also mean: Monthly subscription costs Vendor lock-in Customer conversations stored on third-party platforms Limited customization Another external dependency I wanted something that developers could completely own. The Goal The goal was simple. Build an AI-powered customer support widget that developers can deploy on their own server and integrate into any website in less than a minute. The widget should: Answer customer questions using AI Learn from a custom knowledge base Match the company's branding Store conversation history Allow human handoff Be easy to deploy Require only one script tag to embed Technology Stack Java 17 Spring Boot 3 Spring Security Spring Data JPA Thymeleaf Vanilla JavaScript H2 Database (MySQL supported) OpenAI API Architecture The overall architecture is intentionally simple. Visitor │ ▼ AI Chat Widget (Vanilla JavaScript) │ ▼ Spring Boot REST API │ ▼ OpenAI API │ ▼ Database (H2 / MySQL) Keeping the frontend framework-free makes the widget lightweight and easy to embed into virtually any website. One-Line Integration Adding the widget to a website only requires a single script. <script src="/widget/widget.js" data-api-base=""></sc

Most of us use Spring Boot every day. We create a @RestController, run the application, hit an endpoint from Postman, and get a response. But have you ever wondered what actually happens between clicking "Send" in Postman and your controller method executing? When I started digging into Spring internals, I realized there are several layers working together before my controller is even called. Here's the high-level request flow: Postman │ ▼ Operating System │ ▼ Embedded Tomcat │ ▼ Servlet Filter Chain │ ▼ Spring Security (JWT) │ ▼ DispatcherServlet │ ▼ Controller │ ▼ Service │ ▼ Repository │ ▼ Database What surprised me? One thing I misunderstood for a long time was thinking that the request directly reaches my controller. In reality: The Operating System first routes the request to the application listening on the target port (for example, 8080). Embedded Tomcat accepts the connection. The request passes through the Servlet Filter Chain. Spring Security validates the JWT (if security is enabled). Only after successful authentication does the request reach Spring MVC's DispatcherServlet, which finds the correct controller. This means your controller only executes after several infrastructure components have already processed the request. Key Takeaway Understanding this request flow makes Spring Boot feel much less "magical." Instead of memorizing annotations, you begin to understand why they work. In the next post, I'll explain how Spring Boot starts Embedded Tomcat automatically before the first request even arrives.

After working on enterprise applications and distributed microservices, I have realized that the biggest challenges rarely come from writing business logic. They come from handling production traffic, failures, concurrency, and unexpected edge cases. Here are seven lessons that every Spring Boot developer should know before calling themselves a senior engineer. 1. Never Assume an API Will Be Called Only Once One of the most common mistakes is assuming a client sends exactly one request. In reality: Users refresh the page. Mobile apps retry automatically. API gateways retry requests. Kafka consumers may reprocess events. Network failures cause duplicate submissions. If your endpoint creates an order, payment, or booking every time it receives a request, duplicates are almost guaranteed. Better Approach Design APIs to be idempotent . For example: Use an Idempotency-Key. Store processed request IDs. Ignore duplicate requests safely. Production systems should always expect duplicate requests. 2. Database Transactions Are Not Enough Many developers believe this solves everything: @Transactional public void createOrder () { ... } It doesn't. A transaction protects changes inside a single database . It does not protect: Kafka publishing Email sending External REST APIs Redis updates File uploads If your database commits successfully but Kafka publishing fails, your system is already inconsistent. Better Approach Use patterns such as: Transactional Outbox Saga Pattern Event-driven architecture Retry with dead-letter queues 3. Don't Trust External APIs Every external service will eventually fail. Your payment provider. Your authentication service. Your notification service. Even your own internal microservices. Never assume another service is always available. Add Protection Timeouts Retries Circuit Breakers Fallback logic Monitoring Failing fast is usually better than waiting forever. 4. Logging Is More Valuable Than You Think When production goes down, nobody asks: "Was th

At the end of the previous chapter, I teased that we were about to dive straight into the heavy machinery of DAO implementation - hooking up Spring Data JPA and Hibernate under the hood. If you look at our original roadmap, concrete implementation was supposed to be right here. But after laying down our domain models, data contracts, and reading some of your feedback, I realized that we need to address an unspoken architectural trap first: data mapping and transformation . Most teams blindly adopt automated tools - whether runtime reflection wrappers or compile-time generators like MapStruct - until an architectural mismatch or production incident breaks their service. Before we wire up our database infrastructure, let’s see why we chose to completely bypass mapping "magic" in favor of pure, explicit Java transformers. And yes, some will say that writing explicit transformers is boilerplate - why write it manually when we can just use an annotation? The answer is simple: we’re not building a simple CRUD application that gets thrown to a support team and forgotten. We’re building an enterprise-ready microservice, built for deployment in Kubernetes, integrated with Kafka, Redis, and multi-tenant authorization layers - a product designed to be actively developed and maintained over years, not weeks. This is where the real value shines: spending a little more time writing explicit transformers - as I call them, rather than standard Mappers. I call them transformers because they actively reshape data. A "mapping" usually implies just copying a field from ClassA to ClassB (whether with the same or a different name). We aren't doing that here because at an enterprise level, field names, types, and structural representations will diverge significantly between your database entities, domain models, and external DTOs. The Architectural Trap Across my 11 years in Enterprise Java, I've seen team after team reach for automated mappers to "save time." To understand why we banned

JDK 24 removed the monitor-related carrier-thread pinning that stalled Netflix and similar teams on Java 21. What has replaced it on JDK 25 LTS is downstream-resource saturation: The bottleneck moved and now demands explicit bounding in application code. This article maps the failure modes that surface after virtual-thread adoption and gives a practical sequence backed by a public benchmark. By Sandeep Bharadwaj

Cutting LLM costs in Spring AI starts with two choices: which model answers a request, and what defaults your ChatClient adds to every one it sends. Neither is worth changing until you can see where the tokens go. That is why this article starts with measurement. This is Part 1 of four, and it covers the first three of ten cost drivers. Driver #0 tells you where the money actually goes; #1 and #2 are the two decisions that shape every request your application sends. The remaining seven attach to what you build here. A note on the numbers: where a price ratio matters for the argument (input vs. output, cache read vs. write), this series quotes real July 2026 list prices with a link. All other examples use a flat rate of $1 per million input tokens, so you can redo the calculation with your own provider's price sheet. You should do that, because these prices change every few months. Driver #0 — Spring AI observability measurement: you cannot cut what you cannot see Provider invoices and usage dashboards usually show your spending by model and by token type — input, output, and cached. That is useful, but it is not enough. The numbers cannot tell you which feature, client, or advisor inside your application was responsible for that usage. Spring AI integrates with Spring Boot's Micrometer-based observability to fill this gap. Its core AI components automatically emit that data. ChatModel , EmbeddingModel , and ImageModel implementations (support varies by provider) publish model-level observations, including token usage where available. ChatClient (including advisors) and VectorStore report execution observations and traces rather than token usage metrics. Each metric includes built-in tags, such as the model name and token type. These tags separate models and providers, but not callers: every request to the same model carries the same tag values, so they cannot tell two features apart on their own. Spring AI marks tags as low- or high-cardinality: low-cardinality tags

Spring AI's defaults are built for a fast start; they do not guarantee a low monthly cost. Shipping an LLM feature is easy — making it cost-efficient is not. This series shows the spots where money leaks, along with the control that closes each one. Spring AI 2.0 reached GA on 12 June 2026 . It needs Spring Boot 4 , moves the tool-calling loop out of the ChatModel , adds tool search, and extends structured outputs. Tool search and the extended structured-output controls point in the same direction: they determine how many tokens your application sends and receives. The bill grows quietly. A chatbot with a 2,000-token system prompt, run 100,000 times a month, sends 200 million tokens of the same text. At an example rate of $1 per million input tokens, that is $200 a month — before a single user message. Then add conversation history, which is sent in full on every turn. Add retrieved RAG documents and the JSON schema of every registered tool. The input side can grow 10× with no change in traffic at all. Output tokens cost several times more per token than input tokens, and reasoning models bill their hidden "thinking" as output too. The provider sets the prices. The framework gives you controls that can reduce the number of tokens you pay for. This series works through ten cost drivers, numbered #0 to #9. Each one is a place where tokens repeat or grow without anyone deciding they should, and each comes with the Spring AI control that cuts it. They are spread across four parts. Part 1 is live. Parts 2 to 4 follow in August 2026. Part 1 — Token Usage: Measure Cost Before You Pick a Model (Drivers #0–#2) Provider dashboards show what you spent, but not which feature spent it. Spring AI's observability closes that gap, and from there you can match each model to its task and stop features from carrying defaults they never needed. Part 2 — Prompt Caching and Chat Memory: Where the Tokens Go (Drivers #3–#5) This part covers limiting response length, bounding how much conve

If you have written enterprise Java in the last 20 years, you know the name Rod Johnson. He created Spring Framework back in 2003 - the thing that made Java dependency injection feel natural instead of like wrestling XML. Spring basically rewrote how enterprise Java works. Johnson stepped away from active Spring development years ago. But in early 2026, he returned - and he did not come back to build another IoC container. He built Embabel. An AI agent framework for the JVM. And it works nothing like Spring AI or LangChain4j. I have been running AI agents on my own VPS for months. Hermes Agent, Claude Code, custom MCP servers - the works. So when I heard Rod Johnson was back with a Java AI framework, I paid attention. Here is what I found. Spring AI and LangChain4j Are Great - but They Solve a Different Problem Over the last year, most Java developers entering AI have gravitated toward two frameworks: Spring AI - brings LLM integration into the Spring ecosystem LangChain4j - a Java port of LangChain's agent/tool patterns Both are excellent at what they do. You can build chatbots, RAG pipelines, tool-calling assistants, and AI-powered APIs in a few lines of code. But both treat the LLM as the center of the application. You send a prompt. The model responds. Maybe it calls a tool. Then it responds again. For question-answering or chat interfaces, that is fine. But what if you want the system to: Create a multi-step plan before taking any action Run for 10 minutes, not 10 seconds Check its own work and retry if it failed Coordinate multiple agents working on different parts of a problem This is where the chatbot pattern breaks down. And this is exactly what Embabel targets. What Is Embabel? Embabel (pronounced em-BAY-bel) is a framework for building goal-oriented AI agents on the JVM. It is written in Kotlin and works naturally from Java. It sits on top of Spring AI - Johnson described the relationship as "Spring AI is to Embabel as the Servlet API is to Spring MVC" [

Every developer who has worked with LLMs has been there. You ask the model for JSON. You describe the schema. You say "please only respond with valid JSON." And sometimes, it still breaks. Your application crashes because the model returned a string where you expected an integer. Or it wrapped the JSON in markdown code blocks. Or it omitted a required field. Spring AI 2.0 has a solution that treats this like a real engineering problem instead of a prayer. The Problem When you use structured output in Spring AI, the workflow goes like this: You define a Java type (a record, class, or enum) Spring AI generates a JSON schema from that type The schema gets appended to the prompt sent to the LLM The model returns a response Spring AI attempts to deserialize the response into your type This works well with frontier models like Claude and GPT-4. But smaller open-source models, like Llama 3.2 1B running locally via Ollama, fail more often. They might return null for a primitive field, omit required fields, or produce malformed JSON. When it fails, you get a deserialization exception. Your endpoint returns a 500 error. Spring AI provides no built-in recovery mechanism. The Old Approach: Hope Consider a conference talk submission system. Speakers submit messy, unstructured abstracts. You want to extract structured data: public record TalkSubmission ( String title , String abstractText , Level level , // BEGINNER, INTERMEDIATE, ADVANCED Track track , int duration , List < String > tags , String speakerHandle ) {} Here is what the basic typed response looks like: @PostMapping ( "/typed" ) public TalkSubmission typed ( @RequestBody String rawSubmission ) { return chatClient . prompt () . system ( systemPrompt ) . user ( spec -> spec . text ( "Extract the talk submission: {submission}" ) . param ( "submission" , rawSubmission )) . call () . entity ( TalkSubmission . class ); } You define your type. Spring AI generates the schema and appends it to the prompt. The model gets the in

Kiponos Java SDK 5.0 What’s New — Developer Guide This is the technical companion to the 5.0 milestone announcement: what changed, how modes behave, how to read config with the Folder API, and how to upgrade cleanly. Version 5.0.0.260710 Maven group io.kiponos Artifacts sdk-boot-3 (recommended), sdk-boot-2 (legacy) Released 2026-07-12 (Maven Central) Happy product story: SDK 5.0 milestone post . 1. Summary for busy engineers 5.0 productizes client reliability using a classic state pattern behind a stable facade: Mode When Config reads Mutations / hooks Notes Ready Connected to hub Live in-memory tree Full Production happy path Offline Disconnected but LKG available Last Known Good (read-only) No-op / ignored Survives hub blips without inventing values Safe Fail-closed Empty / null-safe No-op Diagnostic dumps must not overwrite LKG Public entry remains: Kiponos kiponos = Kiponos . createForCurrentTeam (); You do not receive mode instances as the API surface. Modes switch internally. Query with: kiponos . getCurrentMode (); kiponos . isReadyMode (); kiponos . isOfflineMode (); kiponos . isSafeMode (); 2. Install Gradle — Boot 3 repositories { mavenCentral () } dependencies { implementation 'io.kiponos:sdk-boot-3:5.0.0.260710' } Gradle — Boot 2 implementation 'io.kiponos:sdk-boot-2:5.0.0.260710' Runtime inputs Input Mechanism Identity env KIPONOS_ID Access env KIPONOS_ACCESS Profile / tree slice JVM -Dkiponos="['App']['1.0.0']['dev']['base']" Tokens and profile come from the Kiponos Connect screen for your team. sdk-common is not a separate app dependency for consumers — boot jars include shared classes (fat-jar pattern). 3. Architecture (state pattern) Application code │ ▼ Kiponos / KiponosBase ◄── stable facade (one reference for app lifetime) │ ▼ volatile SdkState ├── ReadyMode* → live WebSocket + full Folder ops ├── OfflineMode* → LKG reads only └── SafeMode* → fail-closed + safe diagnostic dump Design rule: never return Ready/Offline/Safe objects to callers. Retur

From answering questions to solving problems — Phase 6 of the Jarvis AI Platform After Phase 5, Jarvis could hear, speak, remember conversations, retrieve documents, and use tools. But every interaction was still limited to a single request and a single response. You: "What's the weather in Kathmandu?" Whisper ↓ AiOrchestrator ↓ WeatherTool ↓ Text-to-Speech Jarvis: "It is 22°C and clear." That works well for simple questions. It completely breaks down when a task requires multiple decisions. The Limitation of Single-Turn AI Imagine asking: Research the top 3 Java AI frameworks, compare them, and summarize the findings. A traditional chatbot usually replies: I don't have enough information to research that. The problem isn't intelligence. The problem is planning. To answer properly, the AI must: Search for Java AI frameworks Search for comparisons Gather information Analyze results Produce a summary That requires multiple tool calls and reasoning between each one. This is exactly what AI agents are designed to do. What Is the ReACT Pattern? ReACT stands for: Reason + Act Instead of generating one response, the AI repeatedly performs a reasoning loop. THINK ↓ ACT ↓ OBSERVE ↓ THINK ↓ ACT ↓ OBSERVE ↓ FINAL ANSWER Example: THOUGHT: I should search for Java AI frameworks. ACTION: search INPUT: Java AI frameworks 2026 ↓ OBSERVATION: Spring AI LangChain4j Semantic Kernel ↓ THOUGHT: Now I need comparison data. ↓ ACTION: search INPUT: Spring AI vs LangChain4j ↓ FINAL ANSWER Instead of guessing everything up front, the AI gathers information step by step before producing the final response. The Biggest Architectural Decision The most important design decision of Phase 6 was not modifying the existing chat pipeline . Instead of turning AiOrchestrator into a giant class responsible for both chat and agents, agents became a completely separate orchestration layer. ❌ Wrong AiOrchestrator ↓ Single Chat ↓ Agent Logic ↓ Tool Logic ↓ Everything Mixed Together ✅ Correct AgentController

Event-driven architecture promises scalability, but in Java-based real-time systems the tradeoffs only surface in production. Drawing on a Java/Kafka contact center platform handling 80k BHCC across 10k agents, this article details where the design breaks down—state management, partition limits, deduplication, JVM tuning, cascading consumer failures—and the Redis-backed patterns that fixed each. By Sagar Deepak Joshi