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!
Opening remarks from Eclipse Foundation and the Jakarta EE China community.
Jakarta EE 12 is being called the Data Age of enterprise Java. Jakarta Data 1.1 adds dynamic queries, a fluent Restriction API and richer metamodel support, while the newly spun-off Jakarta Query 1.0 unifies query expression across relational and NoSQL stores with a two-level design—a portable Core Language plus a Persistence Language—becoming the reference query language for Jakarta Persistence, Jakarta Data and Jakarta NoSQL. This session dissects both specifications: their scope, syntax model and design trade-offs, how they deliver "one query language for SQL and NoSQL" without sacrificing portability, and the practical migration path (with known pitfalls) from existing JPQL and JDQL code.
Enterprise LLMs that "have data but don't understand the business" usually fail for semantic reasons, not volumetric ones: field matching cannot convey business objects, relations and constraints. Starting from the ontology-driven consensus behind Palantir-style platforms, this session argues why "ontology model + semantic alignment" is replacing "dataset + field mapping", and then gets concrete: how to distil an ontology into semantic services callable by LLMs inside a Jakarta EE stack—standard service interfaces and metadata contracts that publish objects, relations and rules to agents, so that where the data is, what it means, how it may be used, and within which boundaries becomes a platform-level capability rather than documentation living outside the systems. A practical path from semantic modelling to service exposure to traceable governance, with public-sector and industry cases, plus how constraint–validation–feedback loops (Harness Engineering) move AI from demo to production.
Efficiency gains from AI coding tools are being paid for with a quality gap: intent drift, contract drift and rework pushed downstream. Spec-Driven Development treats the specification as the single source of truth—humans define WHAT, AI implements HOW—with requirements, design, tasks, code and tests all derived from, and traceable to, the spec. This session breaks down SDD's four pillars, contrasts its flow with Vibe Coding, explains the upstream gap it fills that TDD/BDD never addressed, and shares field-tested practice: how to organise the spec set, how explicit out-of-scope statements constrain AI over-delivery, how version control acts as a safety net, and where scaled adoption usually fails.
The hard question for enterprise Java is not whether you can call an LLM, but which parts of the pipeline may be delegated to it. This session offers a reusable decision line: split inference needs into structured validation, semantic retrieval and generative rewriting, with the error tolerance and fallback strategy appropriate to each. It then traces the evolution path—from vertical-domain fine-tuning, to combining vector search with low-code platforms, to the role of multimodal models in cross-source data processing—supported by measured results from finance and civil-aviation deployments (21.36% recall improvement after domain fine-tuning), and closes with an engineering checklist for introducing inference services safely into a Jakarta EE runtime.
In June 2026 three practitioners independently reached the same conclusion: the engineer's job is shifting from prompting an agent turn by turn to designing the system that prompts it. Loop Engineering names that shift. It sits one level above Harness Engineering—the harness makes a single run reliable; the loop makes that run happen again by itself. This session is a research report: the four-layer evolution from Prompt to Context to Harness to Loop, what each layer does and does not solve; the anatomy of a loop (trigger, execute, verify, record, exit) and its failure modes; and a sober conclusion—a loop faithfully amplifies whatever you bring to it, so once generation becomes cheap, judgement is what stays scarce. It closes with a minimum viable first loop and the guardrails around it.
Four speakers pursue one question: to make AI work in enterprise Java, what should be fixed first—specifications, semantic knowledge, model capability, or engineering method? Every question lands back on it, and the session closes with a shared verdict.
