AI is transforming software engineering. For enterprise Java developers, the key question is whether Java and Jakarta EE are prepared to integrate AI into enterprise applications. The answer is yes.
Java and Jakarta EE already support integration of Large Language Models (LLMs) and AI capabilities through existing APIs, libraries, and frameworks. Developers can continue using the enterprise Java ecosystem without waiting for new specifications. Meanwhile, ongoing initiatives are working to standardize AI programming models within Jakarta EE.
AI and Software Engineering
AI is changing both how developers build software and what applications can do.
AI supports development through code generation, review, testing, documentation, and specification-driven tasks. In applications, it classifies information, generates content, summarizes data, assists users, and participates in business workflows.
As AI becomes more autonomous, its architectural impact grows. Applications may use AI as a simple assistant or allow agents to select tools, execute actions, and manage multi-step workflows.
Greater autonomy heightens the importance of traditional enterprise concerns such as observability, security, governance, predictable boundaries, and operational control.
AI does not remove these concerns; it amplifies them.
Fortunately, enterprise Java already offers many of the architectural foundations needed to confront these challenges.
Jakarta EE and AI Now
Jakarta EE applications can already integrate AI without requiring a fundamentally different application architecture. This is evident in real-world systems. For example, Skillwell Simulate is built with Jakarta EE and integrates with AWS services, including Amazon Bedrock, to deliver AI-powered capabilities.
This example highlights that introducing AI does not require replacing an established enterprise architecture. AI can be integrated as an additional application capability. At the lowest level, an application can communicate directly with providers such as OpenAI, Anthropic, Google, or Amazon Bedrock through their APIs or SDKs.
This approach offers maximum access to provider-specific capabilities but results in tighter coupling. Each provider exposes different APIs, models, configuration methods, and feature sets. This situation naturally leads to the need for abstraction.
Enterprise Java has repeatedly followed a similar architectural evolution: vendor-specific capabilities eventually become accessible through stable abstractions and programming models. AI integration is beginning to follow the same path.
OmniHai is a lightweight Java AI library designed for Jakarta EE and MicroProfile applications. Rather than requiring direct dependencies on each provider SDK, OmniHai offers a consistent AIService abstraction and communicates with providers through their REST APIs.
Using CDI, an AI provider can be injected directly into a Jakarta EE component:
@Inject
@AI(provider = AIProvider.ANTHROPIC,apiKey = "your-anthropic-api-key")
private AIService claude;The application can then interact with the abstraction rather than a provider-specific API:
String response = claude.chat("Explain microservices");This keeps AI integration consistent with familiar Jakarta EE programming models based on dependency injection and managed components.
LangChain4j CDI introduces an additional abstraction layer. Rather than working directly with an AI service object, developers can define an AI service through a Java interface:
@RegisterAIService
public interface AssistantService {
@SystemMessage("You are a helpful assistant.")
String chat(String userMessage);
}Developers do not need to implement the interface manually. The infrastructure generates the implementation and links it to the configured language model.
This progression is important:
Each level exchanges some provider-specific control for greater portability, productivity, and architectural consistency. No single level is universally correct. The best choice depends on the application’s needs for control, abstraction, and portability.
Jakarta EE and Future
Jakarta EE continues to strengthen the enterprise foundations that AI-enabled applications depend on, including persistence and data access. The more directly AI-focused initiative, however, is Jakarta Agentic AI.
Jakarta Agentic AI is developing a standard programming model for building AI agents within the Jakarta EE ecosystem. It does not seek to replace frameworks like LangChain4j or provider SDKs. Instead, it defines common abstractions that help developers create agentic applications consistent with Jakarta EE programming models. This distinction matters.
Enterprise Java need not replicate the entire AI ecosystem. Its strength lies in offering stable programming models, integration points, and abstractions for quickly evolving technologies. AI should be no different.
Conclusion
Enterprise Java is prepared for AI integration. Jakarta EE applications can incorporate language models using provider APIs, lightweight abstractions like OmniHai, or advanced frameworks such as LangChain4j, while continuing the expected architectural standards of enterprise systems.
AI should be seen as an added capability within enterprise architecture, not a replacement. As Jakarta EE evolves and initiatives like Jakarta Agentic AI mature, integrating AI will become more seamless. The focus now is not on whether Enterprise Java can support AI, but on determining the appropriate level of AI autonomy for our applications and defining its boundaries.
