Java Context Options: ThreadLocal vs Scoped Values

Most observability tools can tell you that a request was slow. Few can tell you why. In recent testing conducted by an external engineering partner, we evaluated how Oteligence Maestro extends OpenTelemetry tracing inside a Java application. With the standard OpenTelemetry Java Agent alone, a request trace looked like this: POST /api/orders One span. One total duration. Useful, but it doesn’t reveal what actually happened inside the application. When the same service was run with a Maestro-generated OpenTelemetry extension, the trace automatically revealed the internal execution path of the request: POST /api/orders ↳ createOrder ↳ validateOrder ↳ calculatePricing ↳ processPayment Instead of just seeing that a request took ~300ms, engineers could immediately see where the time was actually spent. Why does this matter? Because most production incidents aren't caused by infrastructure, they're caused by business logic inside the application. And traditional auto-instrumentation rarely exposes that layer. By automatically extending OpenTelemetry with deeper visibility into application execution, Maestro helps teams move from: “Something is slow.” to “This method is responsible.” That shift can dramatically reduce investigation time and speed up root cause identification. We’re excited about what this means for the future of observability, where traces don’t just show requests, but how applications actually execute. #OpenTelemetry #Observability #Java #DevOps #DistributedTracing #PlatformEngineering

🚨 Code Review is not a rubber stamp. If a review only catches formatting, naming, or missing semicolons, the linter should have done that already. Real backend code review is about preventing production problems before they happen. When I open a Pull/Merge Request, these are the things I look for first: 1️⃣ Memory & Resource Leaks • Large objects staying in memory longer than needed • Loading the whole file or too much content into memory for processing. • Collections that can grow without bounds • Streams, files, or DB connections not properly closed Small leaks rarely fail immediately. They slowly become production incidents under load. 2️⃣ Database Efficiency • Fetching full JPA entities when only a few columns are needed • Sequential DB calls that could be batched or parallelized • Hidden N+1 queries inside loops Many “slow APIs” are not compute problems. They are query problems hiding behind ORM abstractions. 3️⃣ Execution Safety • Recursive logic without guaranteed termination • Deep call chains that could cause stack exhaustion • Blocking operations in critical paths Code that works in tests can still fail under real concurrency. 4️⃣ Observability If this fails at 3 AM in production, will we know why? • Are logs meaningful or just noise? • Do we have trace IDs or request correlation? • Can we identify the failing step quickly? Debugging without observability is guesswork. 5️⃣ Failure Handling • What happens if a downstream service times out? • Are timeouts, retries, or fallbacks defined? • Or will threads just hang until the system degrades? Resilience is rarely added later. It must be designed early. 6️⃣ The 6-Month Test If another developer reads this code six months from now, will they understand it immediately? Readable code reduces future bugs. Complex code guarantees them. A code review is not about approving code. It’s about asking: “Is this safe to run in production?” 💬 What is the first red flag that makes you request changes in a Pull Request? #SoftwareEngineering #CodeReview #BackendDevelopment #Java #SpringBoot #SystemDesign #CleanCode

Distributed Transactions are Hard. Here is how to master the SAGA Pattern. 🔄 In a microservices world, we can’t rely on a single BEGIN TRANSACTION and COMMIT because every service has its own database. So, how do we ensure that if a payment fails, the order is canceled and the inventory is restored? The answer is the SAGA Pattern—a way to manage distributed transactions by breaking them into a sequence of small, local transactions. 🏗️ Two Ways to Implement SAGA: 1️⃣ Choreography-Based (Event-Driven) 💃 Each service reacts to events from others without a central leader. Pros: Loose coupling; simple for smaller systems. Cons: Risk of circular dependencies or infinite event loops if not designed carefully. 2️⃣ Orchestration-Based (The Conductor) 🎼 A central "Orchestrator" tells every service exactly what to do and when. Pros: Centralized logic; easier to track and debug complex flows. Cons: The orchestrator can become a complex "God Object" in very large systems. 🛠️ The "Real World" Java Survival Kit To make SAGAs work in production, you need more than just a diagram. You need these three pillars: 📦 The Transactional Outbox Pattern: In Java, we use this to solve the "Dual Write" problem. It ensures that your Database update and your Message Broker (Kafka/RabbitMQ) publish happen atomically. No more lost events! 🛡️ Idempotency is Mandatory: Since events can be redelivered, your services must be idempotent. If your Payment Service receives the same "Charge" event twice, it should only process the payment once. 🔍 Distributed Tracing: For Orchestration, tools like Jaeger or Zipkin are vital. They allow you to attach a "Trace ID" to a transaction so you can visualize exactly where a failure happened across your entire mesh. 💡 The Takeaway: Eventual Consistency SAGA provides Eventual Consistency. Your data may be temporarily inconsistent, but through local transactions and compensating events (undoing changes on failure), it will settle into a correct state eventually. Java Developers: Are you using Spring State Machine for Orchestration or Axon for Choreography? Let’s talk about your stack in the comments! 👇 #Microservices #Java #SpringBoot #SystemDesign #SoftwareEngineering #SagaPattern #Backend #DistributedSystems #Kafka

I recently had the opportunity to present a webinar titled “From Experiment to Enterprise: Building a Full-Stack Java Application Using a Single Prompt." The session explored an interesting question: Can a secure, role-based full-stack application be generated using a single structured prompt? During the webinar, we walked through: 🔹 How structured prompt engineering can orchestrate end-to-end system generation 🔹 A live demo generating a Spring Boot + React application using GitHub Copilot 🔹 Why developer validation, security checks, and governance remain critical in enterprise environments 🔹 How AI can move beyond development acceleration and be embedded inside applications using Spring AI and Retrieval-Augmented Generation (RAG) One of the key takeaways was that AI accelerates scaffolding, but engineers remain responsible for architecture, validation, and production readiness. The webinar is now available as an on-demand video, and you can watch it here: 👉 https://lnkd.in/gkyPuTjF Would love to hear thoughts from others experimenting with AI-assisted development workflows in enterprise environments. #GenAI #Java #SpringBoot #AIAssistedDevelopment #PromptEngineering #SpringAI #SoftwareArchitecture

57,353 lines of code. 194 Java files. 340 classes. 1,140 tests. One developer. One month. No team. Prod green. Tests green. Full build infrastructure. Not a prototype, not a demo project — a Java/JPMS framework with strict modular architecture, JavaFX frontend, custom ID system, LifecycleControl, centralized ResourceSystem, JaCoCo coverage, and a dedicated build plugin. And this isn't cryptic, AI-generated throwaway code. Every class follows a 24-page development guideline with strict naming conventions, contract IDs, Javadoc standards, and architectural patterns. The AI doesn't just generate — it implements to spec. Before a single line of code is written, every module gets a detailed architecture brief. 13 documents totaling over 14,000 lines cover the full stack: architecture, module specs, development process, build system, guidelines, glossary, and backlog. The code for the JFX module is roughly 50% complete — the documentation is already ahead of it. For comparison: Gemini estimates the effort without AI at 3–6 months with 3–5 developers. A senior developer delivers an average of 20–50 debugged, production-ready lines per day. Most of the work isn't typing — it's architecture, debugging, documentation, and tests. That's exactly what changes with AI as a co-developer: implementation happens in seconds instead of hours. Architecture decisions and quality assurance remain with the human. AI doesn't replace developers. But an experienced developer with AI replaces a team. #SoftwareEngineering #AI #Productivity #JavaFX #Claude #Anthropic

Every time you send structured data to an LLM, you're paying for tokens. And if that data is JSON, you're paying for a lot of curly braces, repeated keys, and quotes that add zero information. That's the problem TOON (Token-Oriented Object Notation) solves: a compact, human-readable format that carries the same data as JSON using 30-60% fewer tokens. Field names declared once, indentation instead of braces, minimal quoting. Lossless round-trips to and from JSON. I've been thinking about where things are heading. LLM integrations in enterprise applications are no longer experimental, they're becoming core infrastructure using function calling, tool use, RAG, agentic workflows. All of these involve passing structured data into model context windows, and as these systems scale, token efficiency stops being a nice-to-have and starts being an engineering concern. At the same time, a significant share of enterprise backends run on Spring and Java. That's why I decided to build toon-spring: a Spring Boot library for serializing and deserializing TOON, with the same developer experience you'd expect from Jackson. It's open-sourced, so you can get a look and use it when you want and as you want! toon-spring gives you: → ToonMapper — works like Jackson's ObjectMapper, but for TOON → @ToonField / @ToonIgnore annotations for fine-grained control → Spring Boot auto-configuration with HttpMessageConverter for text/toon → Automatic tabular format detection for uniform object arrays → Configurable delimiters (comma, tab, pipe) and encoding options → Full support for nested objects, primitive arrays, and mixed structures Drop it into your Spring Boot project and you can serialize Java objects to TOON and deserialize TOON into POJOs with a single line of code. This is an early-stage project and there’s a lot of room to grow. I’d love to hear from engineers working at the intersection of Java and AI infrastructure. I’m genuinely looking forward to feedback, discussions, and suggestions from anyone interested in this space, open to constructive ideas and contributions. 🔗 https://lnkd.in/dXQNQ5Hm #Java #SpringBoot #OpenSource #LLM #AI #TOON #SoftwareEngineering

🧵 𝐉𝐚𝐯𝐚 𝐕𝐢𝐫𝐭𝐮𝐚𝐥 𝐓𝐡𝐫𝐞𝐚𝐝𝐬: 𝐓𝐡𝐞 𝐄𝐧𝐝 𝐨𝐟 𝐓𝐡𝐫𝐞𝐚𝐝 𝐏𝐨𝐨𝐥 𝐓𝐮𝐧𝐢𝐧𝐠? With the release of Virtual Threads (Project Loom), Java changed the way we think about concurrency. For years, building scalable systems meant: - Carefully sizing thread pools - Avoiding blocking calls - Fighting context switching - Moving to reactive stacks to survive high concurrency Now? We can create 𝐦𝐢𝐥𝐥𝐢𝐨𝐧𝐬 𝐨𝐟 𝐥𝐢𝐠𝐡𝐭𝐰𝐞𝐢𝐠𝐡𝐭 𝐭𝐡𝐫𝐞𝐚𝐝𝐬, each mapped to a small number of carrier OS threads — managed by the JVM. 𝘵𝘳𝘺 (𝘷𝘢𝘳 𝘦𝘹𝘦𝘤𝘶𝘵𝘰𝘳 = 𝘌𝘹𝘦𝘤𝘶𝘵𝘰𝘳𝘴.𝘯𝘦𝘸𝘝𝘪𝘳𝘵𝘶𝘢𝘭𝘛𝘩𝘳𝘦𝘢𝘥𝘗𝘦𝘳𝘛𝘢𝘴𝘬𝘌𝘹𝘦𝘤𝘶𝘵𝘰𝘳()) {   𝘦𝘹𝘦𝘤𝘶𝘵𝘰𝘳.𝘴𝘶𝘣𝘮𝘪𝘵(() -> 𝘴𝘦𝘳𝘷𝘪𝘤𝘦.𝘱𝘳𝘰𝘤𝘦𝘴𝘴()); } That’s it. 🚀 𝐖𝐡𝐚𝐭’𝐬 𝐫𝐞𝐚𝐥𝐥𝐲 𝐡𝐚𝐩𝐩𝐞𝐧𝐢𝐧𝐠 𝐮𝐧𝐝𝐞𝐫 𝐭𝐡𝐞 𝐡𝐨𝐨𝐝? Virtual Threads are: - Scheduled by the JVM, not the OS - Cheap to create - Parked instead of blocked during I/O - Designed to work beautifully with traditional blocking APIs This means: - Simpler code (no reactive ceremony) - Structured concurrency becomes practical - Thread-per-request is back — but scalable ⚠️ 𝐁𝐮𝐭 𝐡𝐞𝐫𝐞’𝐬 𝐭𝐡𝐞 𝐢𝐧𝐬𝐢𝐠𝐡𝐭: Virtual Threads don’t magically fix: - CPU-bound workloads - Poor database design - Lock contention - Synchronized bottlenecks If your system is limited by CPU or shared resources, Loom won’t save you. 💡 𝐓𝐡𝐞 𝐫𝐞𝐚𝐥 𝐬𝐡𝐢𝐟𝐭 The biggest gain isn’t just performance. It’s cognitive simplicity. We can go back to writing straightforward, imperative code — without sacrificing scalability. And honestly, that’s a big win for maintainability in enterprise systems. #Java #VirtualThreads #ProjectLoom #JVM #BackendDevelopment #SoftwareEngineering #Concurrency #Scalability #HighPerformance #DistributedSystems

Error-driven development. It's not a methodology, it's just what happens when you have 13 problems and a code generator. 🫠 I've added support for more question types in LocalCode (my self-hosted coding platform, you should know by now 🤷♂️). Sounds like a feature. Turned out to be a refactoring project first. Pulled the harness apart, built per-parameter parsers, and landed on an abstraction where adding a new type is just three small classes snapped together. No 400-line switch statements harmed in the process. 🧹 That's three weeks worth of instinctual thought process. I've written about the refactoring, the design, the patterns, and the code that still smells (and why I left it that way) in my latest blog article. Read the blog article 🌐 https://lnkd.in/dyKuA7Kr #opensource #java #springboot #systemdesign #dsa #refactoring

🚀 Just wrapped up a small Proof of Concept using LangChain4j and Hugging Face! I built a simple chat interface where users can type any input and receive AI-generated responses — all powered by Java. This helped me explore how LLMs can be integrated into Java applications with minimal setup. 🔧 Technologies used: LangChain4j (Java) Hugging Face API Spring Boot 📂 https://lnkd.in/gqNyvpzu I’d love to hear your suggestions, feedback, or even contributions if you’re exploring similar ideas. Let’s build and learn together! Here’s a quick architecture diagram of the flow 👇 #Java #LangChain4j #HuggingFace #AI #LLM #SpringBoot #Microservices #Kafka #OpenSource