Sponsor this edition of JakartaOne Livestream!
LangChain4J is the go-to framework for bringing AI to Java. In this session, we’ll take it a step further by integrating langchain4j-cdi and the A2A Java SDK into standard Jakarta Servers. You'll see step-by-step how to leverage dependency injection to eliminate repetitive setup, orchestrate local and remote agent workflows via A2A, and deploy production-ready agentic pipelines on your existing Java runtime.
From OpenID Connect and JWT to classic Form and BASIC authentication, Jakarta Security empowers developers to craft resilient web applications and microservices with unparalleled flexibility.
Among others, Jakarta Security 5 will add a native JWT authentication mechanism, in such a way that an MP implementation can be based upon it, thereby unifying the two without sacrificing compatibility with existing code.
Another big feature will be support for securing Jakarta REST in a Jakarta Security native way (by indexing constraints as permissions into a permission store, which can be programmaticallt queried). We'll provide extensive details on what this support entails.
As the main architect and developer behind this framework I'll explain all you need to know and what we're working on for the next version.
LLMs are probabilistic by nature. Ask the same question twice, get different answers. Great for creativity, terrible for business logic. How do you build reliable systems on top of something inherently unreliable?
Let's tackle this together – from security to predictability. We'll look at guardrails that block prompt injection and redact leaked PII before it leaves your system. Then we'll layer on deterministic validation that catches hallucinations with code, not hope. And when the model gets it wrong, we'll feed errors back for self-correction and use multi-model consensus to build confidence. Practical patterns, real code, no magic.
This isn't about making LLMs perfect – it's about building systems that fail safely and predictably when they're not.
The examples are in Java and LangChain4J; the concepts – transferable to other languages and frameworks.
Writing a Jakarta EE runtime from scratch used to take a team years. Vidocq started as an experiment: could specifications, being precise and testable by design, serve as the input for spec-driven development with AI agents?
Eight months later, Vidocq is a modular open source suite targeting MicroProfile 7.1: Vauban, a build-time CDI 4.1 container based on annotation processing, java Modules-first and using ScopedValue instead of ThreadLocal; Chappe for HTTP; Cassini for Jakarta REST; Champollion for JSON-B and JSON-P; plus MicroProfile Config and Health.
This session is an honest field report. We will look at what makes a specification a good prompt, why the TCK is the only thing that keeps this approach honest, and where AI-generated code creates knowledge debt that a human maintainer has to pay back. We will also cover the community side: licensing, trademark, a nonprofit association, and being asked to leave a public forge because the project is largely AI-generated.
You will leave with a realistic view of what AI-assisted development can and cannot do on a codebase where correctness is defined by a specification.
This talk outlines the current status and roadmap of the Jakarta Agentic AI specification.
AI agents are one of the most prominent developments in enterprise and cloud native computing in decades. They promise to fundamentally accelerate innovation, automation, and productivity by leveraging AI in virtually every industry. Agents operate by leveraging Neural Networks, Machine Learning (ML), Natural Language Processing (NLP), Large Language Models (LLMs), and many other AI technologies to aim to perform specific tasks autonomously with little or no human intervention. They detect events, gather data, generate self-correcting plans, execute actions, process results, and evolve subsequent decisions. Examples include self-driving cars, security monitors, Site Reliability Engineering (SRE) agents, stock monitors, code/application generators, health monitors, customer service agents, manufacturing robots, and many others.
The Agentic AI specification aims to provide a set of APIs that make it easy, consistent, and reliable to build, deploy, and run AI agents on Jakarta EE runtimes. The technology aims to do for developing AI agents what Servlet did for HTTP processing, Jakarta REST did for RESTful web services, or perhaps most appropriately, Jakarta Batch did for batch processing. It defines common usage patterns/life cycles for AI agents, provides a very minimal LLM facade, allows defining dynamic agent workflows that can change at runtime, integrates with other key Jakarta EE APIs such as CDI, Validation, JSON Binding, Persistence, Messaging, and much, much more.
AI agent development is now more prominent in enterprise and cloud -native development. Now, with the Google Agent2Agent (A2A) protocol as the de facto standard, AI agents can discover other AI agents for seamless communication.
But what if developers prefer the advantage of deploying their custom AI agent and exposing it as an HTTP service, just as they currently deploy their enterprise applications as microservices?
In this talk, I showcase an enterprise implementation of the Google A2A server that is fully powered by Jakarta EE features.
Developers can build their own AI Agent and introduce it to other agents by exposing its Agent card and skills, defining what the agent does and the skills it provides to do AI tasks.
With minimal configuration, the AI agent can be deployed to any Jakarta EE server of choice, using the server's existing deployment method.
This talk will benefit existing enterprise Java developers by showing a low barrier to entry for learning these features, offering a manageable learning curve, and minimising impact on integration with existing business services, so developers can build AI Agent applications with ease.
Jakarta Data 1.1 enriches the Jakarta EE 12 Web Profile with powerful new capabilities: type-safe restrictions and expressions,, enhanced annotative querying including First N results and projections, lifecycle events, and enhanced Sort and Limit APIs. Jakarta NoSQL 1.1 extends these features to document, key-value, column, and graph databases. See it all in live action demos.
Virtual threads changed the economics of concurrency in Java. Blocking a thread is now cheap enough that thread-per-request and thread-per-task designs can scale far beyond what traditional platform-thread pools allowed.
But removing the thread bottleneck does not create unlimited capacity. It moves the queue.
A Jakarta EE application can now handle thousands of operations concurrently, even though it has only twenty database connections, because the downstream API has rate limits, memory is finite, transaction throughput is limited, and the various services cannot handle an unrestricted request rate. Initially, higher throughput might be achieved, but this will then be followed by a dramatic increase in tail latency, connection-pool starvation, and retry storms, causing the application to fail more quickly than before.
During this session, we will migrate a working Jakarta EE service from platform threads to managed virtual threads and then run a load test; the bottleneck will shift from the executor to the database and downstream services, after which we will rebuild the application based on explicit concurrency budgets.
As we proceed, we'll look at bounded fan-out, admission control, Jakarta Concurrency's execution limits, bulkheads, timeouts, cancellation, and the metrics required to detect overload before the system collapses.
You will leave with a practical way to answer the question virtual threads do not answer:
Rather than asking “How many tasks can I start?” ask “How much concurrent work can the entire system safely carry out?”
Since its introduction in 2018 as Jakarta EE, the platform has evolved from: Jakarta EE 8, an open-source version of Java EE 8; to Jakarta EE 9, the "big bang" release; to Jakarta EE 10 that introduced the Core Profile; and Jakarta EE 11 that focused on productivity and innovation.
And now, Jakarta EE 12, with plans to stagger the releases of the profiles in 4Q2026 and 1Q2027, will focus on consistency and configuration for the “data age,” and delivers: updates to 25 specifications; introduces two new specifications, Jakarta Query and Jakarta Agentic AI; and sets the baseline to Java 25, the latest LTS release.
This presentation will provide a brief history of JavaEE/Jakarta EE, what's new in Jakarta EE 12 with a focus on the Jakarta EE specifications that define the “data age.”
We are proud to say that this year, sessions at JakartaOne Event are chosen by an independent program committee made up of volunteers from the Jakarta EE and cloud native Java community!
