Forem: Buhake Sindi

Bring AI into your Jakarta EE apps with LangChain4J-CDI

Buhake Sindi — Sat, 24 Jan 2026 19:48:49 +0000

Goal: This article will demonstrate how to add AI features to a Jakarta EE / MicroProfile application using LangChain4J‑CDI, with simple to implement examples that runs on Payara, WildFly, Open Liberty, Helidon, Quarkus or any CDI 4.x compatible runtime.
Note: This is an updated article to the one published on the JAVAPRO's magazine - "04-2025 | Java 25 - Special Edition". Since the release of LangChain4J-CDI version 1.0.0, there's been minor changes, but the fundamental architecture and usage of the library is the same.

What is LangChain4J-CDI?

Langchain4J is a Java library that simplifies the integration of AI and LLMs easier, and with their feature of AI services it provides a declarative and type-safe API for developers to define interfaces that represent AI services, abstracting away the complexities of direct LLM communication

LangChain4J‑CDI is a CDI extension that wires LangChain4J components (chat models, embedding models, memories, retrievers, tools) into your application using familiar Jakarta annotations and MicroProfile Config. You declare an AI service interface and the extension generates and registers a CDI bean that you can inject anywhere (CDI-managed beans, REST resources, EJBs, Schedulers, etc.).

With these key benefits that LangChain4J-CDI provides, enterprise developers will benefit from:

Declarative integration using CDI annotations. LangChain4J AI services interface annotated with @RegisterAIService annotation can be injected as CDI beans.
Flexible component configuration: LangChain4J-CDI config utilizes Microprofile Config to configure various LangChain4J components as config parameters.
Visibility and observability: Observe your LLM input and output AI metrics using observability (Microprofile Telemetry) and service resiliency with Microprofile Fault Tolerance.
Portability: works across Jakarta EE/Microprofile compliant application servers and frameworks.

The Key features provided by Langchain4J Microprofile:

Build with CDI at its core. With @RegisterAIService annotation annotated on a Lanchain4J AI service interface, the AI service proxy becomes CDI discoverable bean ready for injection. LangChain4J-CDI provides 2 CDI service extensions that developers can choose from in order to make their AI service CDI discoverable: CDI portable extension or CDI Build Compatible Extension (introduced in CDI 4.0 and higher).
Langchain4J Microprofile config: Developers can benefit from the power of Microprofile Config to build fundamental elements of LangChain4J such as ChatModel/StreamingChatModel, ChatMessage, ChatMemory, ContentRetriever, ToolProvider(useful for Model Context Protocol, MCP), and more, without requiring developers to write builders to generate such elements.
Langchain4J Microprofile Fault Tolerance: Leveraging the power of Microprofile Fault Tolerance resilience and policies on your existing Lanchain4J AI services (such as @Retry, @Timeout, @RateLimit, @Fallback, etc).
Langchain4J Microprofile Telemetry: When enabled, developers can observer their LLM metrics (that follows the Semantic Conventions for GenAI Metrics), through Open Telemetry.

**Please note:* Langchain4J-CDI is a module developed by the Microprofile members, initially called SmallRye-LLM. It has since been donated to Langchain. The SmallRye-LLM repo on GitHub has been retired.*

Getting started with LangChain4J-CDI

Langchain4J-CDI provides a working example on building a conversational AI agent for a car booking system. This demonstration is inspired by the insightful "Java meets AI" talk from Lize Raes at Devoxx Belgium 2023 (with further contributions from Jean-François James. The original demo is from Dmytro Liubarskyi). Developers can view how the same example are implemented on popular Jakarta EE 10 application servers.

Before we begin, we'll assume that you are familiar with the following:

Java development.
Basic knowledge of Maven.
Basic knowledge of LangChain4J. Lize Raes has written a brilliant article on building an hands-on AI agent with Langchain4J here.

We're using OpenLiberty as application server of choice (you can browse the examples/liberty-car-booking example from the example link provided above) but you can use any Jakarta EE / Microprofile compliant application server that you're comfortable with (see the examples of other application servers that runs the Car Booking example).

Let's start building our own AI service, purely in Java. Please ensure that your project is Mavenized.

The current release of LangChain4J-CDI, as of the time of writing, is 1.0.0 and supports LangChain4J core version 1.10.0, and the community version of 1.10.0-beta18 (the latest at this time of writing).

1) Add dependencies (Maven)

We always import the langchain4j-cdi-core library as your dependency:

<!-- Core CDI integration -->
<dependency>
    <groupId>dev.langchain4j.cdi</groupId>
    <artifactId>langchain4j-cdi-core</artifactId>
    <version>${langchain4j.cdi.version}</version>
</dependency>

where ${langchain4j.cdi.version} is the latest LangChain4J CDI version. The LangChain4J-CDI core module automatically depends on the langchain4j-core module, so you do not need to explicitly add it as a dependency (unless you want to explicitly specify your own langchain4j-core version yourself).

You also need to import a LangChain4J model provider. For this example we'll use Azure Open AI, thus its LangChain4J Maven artifact ID is langchain4j-azure-open-ai.

<dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-azure-open-ai</artifactId>
    <version>${dev.langchain4j.version}</version>
</dependency>

where ${dev.langchain4j.version} is the latest Langchain4J main version (in this case 1.10.0).

2) Configure your model(s) with MicroProfile Config

You can leverage Microprofile Config to define and customize Langchain4J AI service components to be used by your application.

Firstly, we need to add the langchain4j-cdi-config module on our Maven project.

<dependency>
    <groupId>dev.langchain4j.cdi</groupId>
    <artifactId>langchain4j-cdi-config</artifactId>
    <version>${langchain4j.cdi.version}</version>
</dependency>

where ${langchain4j.cdi.version} is the latest LangChain4J CDI version. This requires that your application server supports Microprofile Config.

The Langchain4J-CDI class configuration follow this pattern:

dev.langchain4j.cdi.plugin.<beanName>.<key>=<value>

The dev.langchain4j.cdi.plugin.<beanName>.class property is mandatory as it tells CDI which concrete implementation of the LangChain4J AIServices component is to be assigned it to upon CDI registration.

Optionally, to apply the CDI scope to each of your AI service component, set key as scope in your configuration. The value is the fully-qualified CDI scope annotation name (one of @RequestScoped, @ApplicationScoped, @SessionScoped, @Dependent). The default scope is @ApplicationScoped.

dev.langchain4j.cdi.plugin.<beanName>.scope=jakarta.enterprise.context.ApplicationScoped

And the class builder config configuration follow this pattern:

dev.langchain4j.cdi.plugin.<beanName>.config.<key>=<value>

Every AI service requires (first and foremost) a ChatModel as this interfaces with your LLM. Each model provider provides an implementation of the LangChain4J ChatModel interface. For example, LangChain4J Azure Open AI provider provides its implementation to ChatModel, AzureOpenAiChatModel. Each model provider provides a Builder, which is builder pattern to build their corresponding ChatModel object. For LangChain4J Azure Open AI, AzureOpenAiChatModel.Builder build its AzureOpenAiChatModel and the builder config properties uses its builder, where <key> is the builder method of the same name, and the <value> is the corresponding value that is passed to the builder's method.

In our microprofile-config.properties we set our ChatModel as shown below:

dev.langchain4j.cdi.plugin.chat-model.class=dev.langchain4j.model.azure.AzureOpenAiChatModel
dev.langchain4j.cdi.plugin.chat-model.config.api-key=${azure.openai.api.key}
dev.langchain4j.cdi.plugin.chat-model.config.endpoint=${azure.openai.endpoint}
dev.langchain4j.cdi.plugin.chat-model.config.service-version=2024-02-15-preview
dev.langchain4j.cdi.plugin.chat-model.config.deployment-name=${azure.openai.deployment.name}
dev.langchain4j.cdi.plugin.chat-model.config.temperature=0.1
dev.langchain4j.cdi.plugin.chat-model.config.topP=0.1
dev.langchain4j.cdi.plugin.chat-model.config.timeout=PT120S
dev.langchain4j.cdi.plugin.chat-model.config.max-retries=2
dev.langchain4j.cdi.plugin.chat-model.config.logRequestsAndResponses=true

The <beanName> is the CDI bean name that will be assigned to the object class key dev.langchain4j.cdi.plugin.<beanName>.<key>. In this example, the bean name for our chat model is chat-model and it's assigned to the chat model class dev.langchain4j.model.azure.AzureOpenAiChatModel.

All the properties found within the langchain4j.cdi.plugin.<beanName>.config.<key> property, LangChain4J CDI will populate the value to its corresponding Langchain4J ChatModel declared. In this case the dev.langchain4j.model.azure.AzureOpenAiChatModel.Builder class (this is done for you internally).

The <value> builder property can follow the lowercase dashed property value that matches the camel case builder property bean.

For example, should you want to log all chat request you will need to set the logRequests to true on the Builder. In the config, all uppercase letters can be lowered and prepended with a dash -.

dev.langchain4j.cdi.plugin.chat-model.config.log-requests=true

Is equivalent to the config property:

dev.langchain4j.cdi.plugin.chat-model.config.logRequests=true

The config creator (internally) will identify config values that contains dashes and rework it to its camel-case property and match it to the Builder and then assign the value accordingly.

3) Declare an AI Service interface

Using LangChain4J's AiServices, it allows developers the ability to plugin any of the AiServices component much more flexible. Now, we're powering the AI Services with the power of Jakarta EE CDI.

3.1) The @RegisterAiService annotation.

The @RegisterAIService annotation is the glue that automatically applies LangChain4J AI services components to your AI services. Each annotation attribute correspond to the LangChain4J AI service component by their CDI bean name. If any of the property name is assigned as #default then CDI container will find the default AI Services component (based on the component class type) that is ready for injection.

3.2) Your AI Service agent

import dev.langchain4j.service.UserMessage;
import dev.langchain4j.service.SystemMessage;
import dev.langchain4j.cdi.RegisterAiService;

@RegisterAIService(
    scope = ApplicationScoped.class,
    chatLanguageModelName = "chat-model"
)
public interface Assistant {

    @SystemMessage("You are a concise enterprise assistant.")
    @UserMessage("Answer clearly: {{question}}")
    String answer(String question);
}

The interface describes what we want: a Assistant object with one method: answer(String). We specify a SystemMessage (this is optional).

The input is a String, so LangChain4J will infer that this is the UserMessage.
The output is a String, so LangChain4J will automatically infer that this is the model output.

The @RegisterAIService.chatLanguageModelName property matches the <beanName> value that we've specified on the config property file.

The default CDI scope for your AI Service is RequestScoped. You can apply an alternative CDI scope by overriding the @RegisterAIService.scope property.

3.3) Adding Memory

LLMs are stateless, meaning it doesn't remember your previous conversation and context. One way that LLMs remember the conversation is to pass the previous messages and append the current message at every call. It's for that reason that LangChain4J provide the ChatMemory component.
A ChatMemory is basically a list of ChatMessages and you can manually add the messages for every UserMessage you send and every AiMessage you receive back. But if you combine ChatMemory with an AiService, LangChain4J will take care of updating the memory for you.

Please note that adding memory eats tokens, so please monitor your usage cost.

You can configure ChatMemory with Microprofile Config, as follows:

dev.langchain4j.cdi.plugin.chat-memory.class=dev.langchain4j.memory.chat.MessageWindowChatMemory
dev.langchain4j.cdi.plugin.chat-memory.scope=jakarta.enterprise.context.ApplicationScoped
dev.langchain4j.cdi.plugin.chat-memory.config.maxMessages=10

which is equivalent to physically write the code as:

ChatMemory chatMemory = MessageWindowChatMemory.withMaxMessages(10);

Now, we update our existing Assistant @RegisterAIService to include ChatMemory with chatMemoryName property to bean chat-memory:

@RegisterAIService(
    chatLanguageModelName = "chat-model",
    chatMemoryName = "chat-memory"
)

3.4) Adding Tools

There are various ways to add tools for CDI registration:

Either add a fully-qualified class name of class(es) that contains the LangChain4J @Tool annotations on @RegisterAIService.tools annotation property (the tools property is type of Class<?>[]), OR
Specify a @RegisterAIService.toolProviderName for a declared LangChain4J ToolProvider. The ToolProvider can be declared using the configurable properties approach.

For example, if you want to connect to an MCP server, LangChain4J provides an integration to any MCP server through their provided McpToolProvider.

3.5) RAG (Retrieval-Augmented Generation)

LangChain4J provides the interfaces ContentRetriever that you can implement. It provides 4 implementations out of the box, that you can use:

WebSearchEngineContentRetriever: the LLM turns the original prompt into a web search query and a number of search results are used as context
SqlContentRetriever: the LLM is given the database schema and turns the original prompt into SQL to retrieve information that will be used as context
Neo4jContentRetriever: the LLM is given the schema and turns the original prompt into Cypher (neo4j query) to retrieve information that will be used as context
EmbeddingStoreContentRetriever: to retrieve relevant fragments from all documents that we provide (text, excel, images, audio, …).

The scope for building easy RAG and advance RAG using LangChain4J is beyond the scope of this article, but for this example we'll include a simple easy RAG using the configurable approach:

dev.langchain4j.cdi.plugin.docRagRetriever.class=dev.langchain4j.rag.content.retriever.EmbeddingStoreContentRetriever
dev.langchain4j.cdi.plugin.docRagRetriever.config.embeddingStore=lookup:default
dev.langchain4j.cdi.plugin.docRagRetriever.config.embeddingModel=lookup:default
dev.langchain4j.cdi.plugin.docRagRetriever.config.maxResults=3
dev.langchain4j.cdi.plugin.docRagRetriever.config.minScore=0.6

The lookup:default value will cause CDI to lookup the default EmbeddingStore or EmbeddingModel registered in the CDI container. Otherwise, provide a fully-qualified class name of the specified interface class type.

Our EmbeddingModel and EmbeddingStore are CDI produced using CDI producer fields.

@ApplicationScoped
public class DocRagIngestor {

    // Used by ContentRetriever
    @Produces
    private EmbeddingModel embeddingModel = new AllMiniLmL6V2EmbeddingModel();

    // Used by ContentRetriever
    @Produces
    private EmbeddingStore<TextSegment> embeddingStore = new InMemoryEmbeddingStore<>();

    //Code made short for brevity   
}

Then we register it to @RegisterAIService by providing the CDI name of the ContentRetriever as follows:

@RegisterAIService(
    chatLanguageModelName = "chat-model",
    chatMemoryName = "chat-memory",
    contentRetrieverName = "docRagRetriever"
)

4) Inject and use it

Now, you can simply @Inject your AI Assistant.
In this example, our ChatResource RESTful Service (using Jakarta RESTful Web Service) we just inject our Assistant just we normally do with any Jakarta EE CDI services:

import jakarta.inject.Inject;
import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;
import org.eclipse.microprofile.openapi.annotation.Operation;

@Path("/assist")
public class AssistantResource {
    @Inject Assistant assistant;

    @POST
    @Operation(summary = "Ask your question to our friendly assistant.")
    @Path("/ask")
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    public AnswerDto ask(QuestionDto q) {
        return new AnswerDto(assistant.answer(q.getQuestion()));
    }
}

Your AnswerDto and QuestionDto are standard POJO.

public class QuestionDto implements Serializable {

    @JsonbProperty
    private String question;

    public QuestionDto() {}

    public QuestionDto(String question) { 
        this.question = question; 
    }

    public String getQuestion() { 
        return question; 
    }

    public void setQuestion(String question) { 
        this.question = question; 
    }
}

public class AnswerDto implements Serializable {

    @JsonbProperty
    private String answer;

    public AnswerDto() {}

    public AnswerDto(String answer) { 
        this.answer = answer; 
    }

    public String getAnswer() { 
        return answer; 
    }

    public void setAnswer(String answer) { 
        this.answer = answer; 
    }
}

Now, you can run your application by deploying it to your application server and do an HTTP POST to your RESTful endpoint.

4) Observability and resiliency.

4.1) Fault Tolerance using Microprofile Fault Tolerance.

Fault Tolerance capability was added to ensure system stability and resilience to your LangChain4J-CDI AI Services applications. With Microprofile Fault Tolerance integration, AI services can apply features like:

Circuit Breaker: Prevents cascading failures by quickly failing requests to services experiencing issues, allowing them to recover. Use annotation @org.eclipse.microprofile.faulttolerance.CircuitBreaker.
Rate Limiter: Controls the rate of requests to a service, preventing overload.
Retry: Automatically retries failed operations, useful for transient errors. Use annotation @org.eclipse.microprofile.faulttolerance.Retry.
Bulkhead: Isolates failing parts of the system to prevent them from affecting others. Use annotation @org.eclipse.microprofile.faulttolerance.Bulkhead.
Time Limiter: Enforces a timeout on operations, preventing long-running or hung calls. Use annotation @org.eclipse.microprofile.faulttolerance.Timeout.
Fallback: Utilize fallback mechanisms to provide alternative responses or default behavior when an AI model or external service is unavailable or returns an error. Use annotation @org.eclipse.microprofile.faulttolerance.Fallback.
Asynchronous For asynchronous processing for long-running operations. Use annotation @org.eclipse.microprofile.faulttolerance.Asynchronous.

This example (found on examples/liberty-car-booking) utilizes Microprofile Fault Tolerance to ensure resiliency.

@RegisterAIService(scope = ApplicationScoped.class, tools = BookingService.class, chatMemoryName = "chat-ai-service-memory")
public interface ChatAiService {

    @SystemMessage("""
            You are a customer support agent of a car rental company named 'Miles of Smiles'.
            Before providing information about booking or canceling a booking, you MUST always check:
            booking number, customer name and surname.
            You should not answer to any request not related to car booking or Miles of Smiles company general information.
            When a customer wants to cancel a booking, you must check his name and the Miles of Smiles cancellation policy first.
            Any cancelation request must comply with cancellation policy both for the delay and the duration.
            Today is {{current_date}}.
            """)
    @Timeout(unit = ChronoUnit.MINUTES, value = 5)
    @Retry(abortOn = { BookingCannotBeCanceledException.class,
            BookingAlreadyCanceledException.class,
            BookingNotFoundException.class }, maxRetries = 2)
    @Fallback(fallbackMethod = "chatFallback", skipOn = {
            BookingCannotBeCanceledException.class,
            BookingAlreadyCanceledException.class,
            BookingNotFoundException.class })
    String chat(String question);

    default String chatFallback(String question) {
        return String.format(
                "Sorry, I am not able to answer your request %s at the moment. Please try again later.",
                question);
    }
}

Please note that LangChain4J ChatModel has a retry policy built inside the ChatModel.chat() method. Thus, adding a @Retry to your AI Service will add additional retry maxRetries to its existing LangChain4J ChatModel maxRetries. Some LangChain4J AI providers do provide the ability to configure the maxRetries so we suggest to set the ChatModel.maxRetries = 0 in order to fully rely on Microprofile's Fault Tolerance retry mechanism.

To apply fault tolerance to our AI services, we need to add the langchain4j-cdi-fault-tolerance module on our Maven project.

<dependency>
    <groupId>dev.langchain4j.cdi.mp</groupId>
    <artifactId>langchain4j-cdi-fault-tolerance</artifactId>
    <version>${langchain4j.cdi.version}</version>
</dependency>

where ${langchain4j.cdi.version} is the latest LangChain4J CDI version. This requires that your application server supports Microprofile Fault Tolerance.

4.2) Observability using Microprofile Telemetry

LangChain4J-CDI Telemetry builds upon the observability features in the Microprofile Telemetry to provide insights into AI-related operations. LangChain4J-CDI Telemetry provides metrics and tracing capabilities for the ChatModel component, based on the Semantic Conventions for GenAI Metrics).

To apply Generative AI telemetry to our AI services, we need to add the langchain4j-cdi-telemetry module on our Maven project.

<dependency>
    <groupId>dev.langchain4j.cdi.mp</groupId>
    <artifactId>langchain4j-cdi-telemetry</artifactId>
    <version>${langchain4j.cdi.version}</version>
</dependency>

where ${langchain4j.cdi.version} is the latest LangChain4J CDI version. This requires that your application server supports Microprofile Telemetry.

The LangChain4J-CDI Telemetry provides 2 implementation of the ChatModelListener:

dev.langchain4j.cdi.telemetry.SpanChatModelListener: To represent a span for every ChatModelRequest call to Generative AI model or service and a ChatModelResponse based on the input prompt.
dev.langchain4j.cdi.telemetry.MetricsChatModelListener: To represent generative AI metrics for every ChatModelRequest to the LLM, along with its ChatModelResponse.

Using the configurable properties method, we can apply the following ChatModelListener to our ChatModel as follows:

dev.langchain4j.cdi.plugin.<beanName>.config.listeners=@all

The value set to @all tells CDI to inject all CDI discoverable ChatModelListener to the ChatModel that supports listeners.

Alternatively, you can specify your ChatModel individually as follows:

dev.langchain4j.cdi.plugin.<beanName>.config.listeners=dev.langchain4j.cdi.telemetry.SpanChatModelListener,dev.langchain4j.cdi.telemetry.MetricsChatModelListener

The value are comma separated, fully qualified class name. The class must implement the ChatModelListener interface.

In Summary

LangChain4J-CDI simplifies the process of integrating LangChain4J components into AI services. Its strong CDI integration and pluggability to MicroProfile, LangChain4J-CDI makes it an attractive choice for Jakarta EE and Microprofile developers who want to add LangChain4J AI capabilities without the usual overhead and boilerplate code. Thus, LangChain4J-CDI lets you focus on the value that generative AI can bring to your business logic.

Important Links

LangChain4J-CDI GitHub Repo: https://github.com/langchain4j/langchain4j-cdi/
LangChain4J-CDI Examples GitHub Repo: https://github.com/langchain4j/langchain4j-cdi/tree/main/examples
"Build AI Apps and Agents in Java: Hands-On with LangChain4" by Lize Raes: https://javapro.io/2025/04/23/build-ai-apps-and-agents-in-java-hands-on-with-langchain4j/

You are welcome to contribute too. Please follow our contribution guidelines should you find bugs that you want to raise as an issue or if you have anything worth contributing to the project.

LangChain4J-CDI is a project built and maintained by the Jakarta EE/MicroProfile Working Group, under the LangChain4J umbrella.
Thank you to the Microprofile AI team: Emily Jiang, Emmanuel Hugonnet, Yann Blazart, Ed Burns, Arjav Desai, Phil Chung, Luis Neto, John Clingan, Clement Escoffer, Buhake Sindi, Don Bourne, and other contributors for their immense contribution to the LangChain4J-CDI project.

Introducing SmallRye LLM - Injecting Langchain4J AI Service for Java developers.

Buhake Sindi — Sat, 12 Apr 2025 06:17:02 +0000

If you're a Java developer wanting to build AI agents or interface with various Large Language Models (LLM) in Java you will be familiar with Langchain4J.

What is Langchain4J (simplified)?

LangChain4J is essentially a toolbox for Java developers that makes it easier to add advanced language AI capabilities (like chatbots or text generators) to their applications, without having to deal with a ton of complicated details.

Imagine you want to build a smart app that can answer questions, generate content, or chat like a human. Normally, to talk to an artificial intelligence model (such as ChatGPT or similar), you have to learn different interfaces and deal with lots of technical stuff. LangChain4J simplifies all of that by providing a set of ready-made tools and a standard way (a unified API) to interact with various AI providers and related services—all within Java.

Here’s a breakdown in simple terms:

Unified Interface: Instead of figuring out how each AI provider works, LangChain4J gives you one common interface to work with. This means if you want to switch from one AI service to another, you usually don’t have to rewrite your entire code.
Built-in Tools: It comes with many handy features. For example, it can manage conversation history (so your chatbot “remembers” what was said earlier), help format and manage prompts that are sent to the AI, and even assist with tasks like searching and storing text in a way that makes it easy for the AI to work with.
Easier Integration: Think of it like a connector or an adapter that plugs the powerful capabilities of modern AI models into your Java application without you needing to worry about the low-level details.
Ready-to-Use Examples: LangChain4J offers examples and patterns so you can quickly see how to use these AI features, whether you’re building a customer support chatbot, an educational tool, or a sophisticated search engine.

In short, if you’re a Java developer wanting to build an AI-powered app, LangChain4J gives you a smoother, simpler way to tap into the power of large language models without starting from scratch or getting tangled in the complex details of each individual AI service.

Langchain4J Ai service

Langchain4J introduced AI services, a high‑level API that abstracts and automates the many steps required to integrate large language models (LLMs) into a Java application. Instead of manually constructing prompts, handling context (or chat memory), formatting outputs, and managing tools or external data retrieval, you simply define a plain Java interface that represents the “service” you want to build. The framework then creates a proxy implementation of that interface, which automatically takes care of converting your method calls into the underlying low‑level operations needed to communicate with the LLM.

LangChain4J AI Services lets you sidestep all this complexity. You simply create an interface like this:

    interface Assistant {
        @UserMessage("Answer this question: {{it}}")
        String chat(String userMessage);
    }

Then, by calling a builder method from AI Services, you receive an object that implements this interface. When you invoke the chat method, the framework automatically:

Converts your plain string into the proper LLM input (often wrapping it as a “user message”).
Attaches any preset system instructions you may have provided (using annotations like @SystemMessage).
Optionally manages and appends the conversation history if you have configured chat memory.
Sends the composed prompt to the LLM.
Parses and converts the output back into a Java type (in this case, a String).

Langchain4J in enterprise Java

For enterprise Java developers, the idea of creating modular and loosely-coupled applications and having component frameworks to injecting interfaces based on business requirements is what makes building enterprise-ready applications in Java beautiful.

There are various enterprise Java frameworks that have Langchain4J integration to build AI‑powered applications (such as chatbots and content summarizers) with minimal configuration and boilerplate code.

Langchain4J Spring: integration of LangChain4J framework with the Spring ecosystem - typically Spring Boot.
Quarkus Langchain4J: integration of LangChain4J with the Quarkus framework

These above-mentioned frameworks leverages on the their respective framework capabilites and benefits by abstracting away the complexity of LLM interactions, thus ensuring that developers write robust, clean and module AI Services.

But what about Jakarta EE? If you're familiar with Jakarta EE, it provides various frameworks where interfaces are declared and used for injection, with minimal configuration while abstracting the complexities of the framework (Jakarta Persistence, JPA comes to mind).

Introducing Langchain4J Microprofile with SmallRye-LLM.

Langchain4J Microprofile (currently known as SmallRye LLM, an Eclipse Microprofile Project) is a lightweight Java library that brings Langchain4J AI services capabilities into the Jakarta EE, MicroProfile and Quarkus ecosystems. This means that it leverages familiar dependency injection (CDI), configuration via MicroProfile Config, and other MicroProfile standards.

The Key features provided by Langchain4J Microprofile:

Build with CDI at its core. With @RegisterAIService annotation annotated on a Lanchain4J AI service interface, the AI service proxy becomes CDI discoverable bean ready for injection. There are 2 CDI service extensions provided that developers can select to make their AI service CDI discoverable: CDI portable extension or CDI Build Compatible Extension (introduced in CDI 4.0 and higher).
Langchain4J Microprofile config: Developers can benefit from the power of Microprofile Config to build fundamental elements of Langchain4J such as ChatLanguageModel, ChatMessage, ChatMemory, ContentRetriever, ToolProvider(useful for Model Context Protocol, MCP), and more, without requiring developers to write builders to generate such elements.
Langchain4J Microprofile Fault Tolerance: Leveraging the power of Microprofile Fault Tolerance on your existing Lanchain4J AI services (such as @Retry, @Timeout, @RateLimit, Fallback, etc).
Langchain4J Microprofile Telemetry: When enabled, developers can observer their LLM metrics (that follows the Semantic Conventions for GenAI Metrics), through Open Telemetry.

Langchain4J Microprofile examples.

There are existing examples provided that showcase the power of Langchain4J Microprofile feature set. These examples is based on a simplified car booking application inspired from the Java meets AI talk from Lize Raes at Devoxx Belgium 2023 with additional work from Jean-François James. The original demo is from Dmytro Liubarskyi.

The Car Booking examples run on the following environments:

GlassFish
Payara
Helidon (both with CDI Build Compatible Extension and CDI Portable Extension)
Open Liberty
Wildfly
Quarkus

Building your own Langchain4J AI Service.

In this example, we'll build our own Assistant AI Service (see code above) using Langchain4J Microprofile. Please ensure that your project is Mavenized.

The current release (as of the time of writing is 0.0.4 and supports Langchain4J version 1.0.0-beta2 (the latest at this time of writing).

Import SmallRye-LLM Portable Extension to your project. This will enable your AI service(s) to be registered for CDI injection.

    <dependency>
        <groupId>io.smallrye.llm</groupId>
        <artifactId>smallrye-llm-langchain4j-portable-extension</artifactId>
        <version>0.0.4</version>
    </dependency>

Import SmallRye-LLM Microprofile Config. This will allow us to create Langchain4J features using the power of Microprofile Config specification:

    <dependency>
        <groupId>io.smallrye.llm</groupId>
        <artifactId>smallrye-llm-langchain4j-config-mpconfig</artifactId>
        <version>0.0.4</version>
    </dependency>

Annotate your Langchain4J AI service with @RegisterAIService and provide a name for your ChatLanguageModel (this name will be used by CDI container, more about it later).

    @RegisterAIService(chatLanguageModelName = "chat-model-openai")
    interface Assistant {
        @UserMessage("Answer this question: {{it}}")
        String chat(String userMessage);
    }

Configure your ChatLanguageModel object in your microprofile-config.properties (most application provide this file inside resources\META-INF folder).

For this example, we'll use the AzureOpenAiChatModel. When configuring such a model, Langchain4J comes with a Builder that allows you to build a reference of ChatLanguageModel, depending on the LLM that you select.

A typical way one would create a ChatLanguageModel programmatically (using Olllama in this case):

    private static final String MODEL = "mistral";
    private static final String BASE_URL = "http://localhost:11434";

    ChatLanguageModel model = OllamaChatModel.builder()
                    .baseUrl(BASE_URL)
                    .modelName(MODEL)
                    .temperature(0.2)
                    .timeout(timeout)
                    .build();

With Microprofile Config enabled, we can provide the same feature as a configuration:

The configuration format for any feature relies that the Object has a Builder provided by Langchain4J, otherwise it will break.

The configuration to build the feature is of the following format:

    smallrye.llm.plugin.<cdi-model-name>.config.<builder-property-method-name>=<value>

Example, to create AzureOpenAiChatModel using its Builder internally by CDI, we've configured it as follows:

    smallrye.llm.plugin.chat-model-openai.class=dev.langchain4j.model.azure.AzureOpenAiChatModel
    smallrye.llm.plugin.chat-model-openai.config.api-key=${azure.openai.api.key}
    smallrye.llm.plugin.chat-model-openai.config.endpoint=${azure.openai.endpoint}
    smallrye.llm.plugin.chat-model-openai.config.service-version=2024-02-15-preview
    smallrye.llm.plugin.chat-model-openai.config.deployment-name=${azure.openai.deployment.name}
    smallrye.llm.plugin.chat-model-openai.config.temperature=0.1
    smallrye.llm.plugin.chat-model-openai.config.topP=0.1
    smallrye.llm.plugin.chat-model-openai.config.timeout=PT120S
    smallrye.llm.plugin.chat-model-openai.config.max-retries=2
    smallrye.llm.plugin.chat-model-openai.config.logRequestsAndResponses=true

The configuration must start with smallrye.llm.plugin in order for the CDI extension to detect the Langchain4J configuration. Next we, specify a CDI name for our ChatLanguageModel. In this case it's named chat-model-openai. That's the same name we provided on the @RegisterAIService which tells CDI that it must find the chat-ai-openai ChatLanguageModeland register it to Langchain4J when building Assistant AI service.
The builder-property-method-name is case-sensitive (is named exactly as found on Builder.<builder-property-method-name>(<value>) structure.

By default, all objects configured with Microprofile config is @ApplicationScoped, unless specified otherwise.

And that's it! 😉

Now, you can simply @Inject it in your enterprise business service. Example, our ChatResource RESTful Service (using Jakarta RESTful Web Service) we just inject our Assistant just we normally do with any Jakarta EE CDI services:


    @Path("/chat")
    public class ChatResource {

        @Inject
        private Assistant assistant;

        @GET
        @Operation(summary = "Chat to our friendly assistant.")
        @Produces(MediaType.TEXT_PLAIN)
        public String chat(@QueryParam("message") String message) {
            return assistant.chat(message);
        }
    }

Additional features: If you want to explore your LLM metrics using Microprofile Telemetry (running Open Telemetry), add the following feature to your microprofile-config.properties.

This example enables CDI discovery to find all ChatModelListener and inject them automatically:

    smallrye.llm.plugin.chat-model.config.listeners=@all

Or similarly, if you want to include specific ChatModelListener:

    smallrye.llm.plugin.chat-model.config.listeners=io.smallrye.llm.langchain4j.telemetry.SpanChatModelListener,io.smallrye.llm.langchain4j.telemetry.MetricsChatModelListener

Please visit the SmallRye-LLM examples to see all the further features that we've included.

In Summary

SmallRye LLM simplifies the process of integrating Langchain4J AI services features into your Microprofile applications. Its tight integration with MicroProfile and unified API makes it an attractive choice for Jakarta EE and Microprofile developers who want to add AI capabilities without the usual overhead and boilerplate. Thus, SmallRye LLM lets you focus on the value that generative AI can bring to your business logic.

Exciting news for Java developers

Buhake Sindi — Wed, 19 Mar 2025 19:23:36 +0000

Today is the day for Java developers:

JavaOne'25 has officially started (March 18 - 20, 2025) at Redwood Shores, CA, U.S.A.
Java 24 is now available. You can view all the JDK 24 features here and download it here.
Oracle has launched Learn.java, a place where everyone (from learners, teachers, and enthusiasts) can learn about Java and learn Java.

You can watch the Java 24 Launch on the official Java YouTube channel.

Time to start updating and happy coding! ☕

Why Java Developers Should Choose Jakarta EE / Microprofile Framework

Buhake Sindi — Mon, 10 Mar 2025 02:09:56 +0000

Java is 30 years old (at the time of writing this post) and it's still among the top 3 most popular programming language in the world. It's a language that has been easily adopted worldwide by many enterprises worldwide. This is due to the adoption of its popular ecosystems, one of which is the Enterprise Java ecosystem, Jakarta EE.

Now, the barrier to entry for Java developers in building enterprise applications has never been easier than ever. With its vast offerings of specifications, stable & modular architecture, seamless integrations between APIs and libraries while taking full advantages of the Java SE platforms, we explore why Jakarta IS and should be the framework of choice for Java developers and how/why it remains the popular enterprise Java framework worldwide.

Before we begin

Frameworks are not new. Without frameworks, developers would have to worry on integrating with various platforms and infrastructures, apply compliant security standards, make code modular and stable and ensure that it can scale as business requirement demands grows. Ultimately, frameworks exists to let developers focus on building stable business logic while the technical glue of the application are handled within the framework code.

The Jakarta EE framework.

Jakarta EE is not new. It started around 1998 as a JPE project but it grew to become J2EE (which introduced Servlet, JSP, EJB, to SOAP Web service, JAX-WS) and later transitioned to Java EE (which introduced EJB 3, JPA, JSF, CDI, Bean validations, JSON-B, etc) to becoming the modern Jakarta EE (after it migrated from Oracle to the Eclipse Foundation in 2017). I did a full presentation about the history of Java EE/Jakarta EE and you can view it here (slides here).

Thus, Jakarta EE specifies an open-source set of Application Programming Interfaces (APIs) and a runtime environment to develop and run secure, scalable enterprise-level Java applications.

This has its benefits and advantages:

Jakarta EE is the de-facto standard with a set of specifications for building enterprise Java applications. It is well-understood and widely accepted because of its stability, portability, and backwards compatibility.
Jakarta EE is vendor-neutral, meaning multiple vendors implement Jakarta EE specifications, allowing developers to choose the best runtime based on your needs without vendor lock-in.
Stability and Maturity: Well-established standard with a long history, ensuring reliability for building mission-critical applications.
Portability: Applications built on Jakarta EE standards can run on different compatible application servers due to the standardized APIs.
Community-driven: The Jakarta EE Working Group (the global community of leading technology organizations and individuals) offers flexible membership options so that organizations at all stages of development can participate. They use an open process to make decisions and generate specifications and is always looking for community feedback and uses it to innovate and evolve the platform.

Jakarta EE relevancy

Jakarta EE relevancy can be seen in the adoption and/or implementation of the Jakarta EE specifications. The Jakarta EE compatible products ensures that your Jakarta EE application runs as intended, according to its Jakarta EE specification.

In addition, there are many more products, tools, and frameworks that have adopted and/or implemented some of the individual specifications from Jakarta EE. Prime Faces is a popular frontend UI component library that is built upon Jakarta Faces (previously known as JSF). Spring Framework also relies on Jakarta EE technologies, such as Servlets for their web offerings, Jakarta Persistence (previously known as JPA) as part of their Spring Data offering.

Designed with innovations in mind

Jakarta EE introduces features for building modernized, simplified, and lightweight cloud-native Java applications. Eclipse MicroProfile are a good example of technologies that rely on Jakarta EE for their cloud-native enterprise Java applications.

Specifications in Jakarta EE

The current Jakarta EE Platform (Jakarta EE 10 Platform at the time of writing) consists of module specifications, some of which are bundled under a specific profile.

The Jakarta EE Web Profile defines a profile of the Jakarta EE Platform specifically targeted at web applications. Tomcat is a famous servlet container that implements Jakarta EE Web Profile.
The Jakarta EE Core Profile is a new profile of the Jakarta EE platform specifically targeted at smaller runtimes. This enables the development of modernized and lightweight Java applications and microservices. Eclipse Microprofile specifies Jakarta EE Core Profile as its dependency.

Why choose Jakarta EE over other Java enterprise frameworks?

Payara have summarized it best:

You need standardization across a large organization
- Long-term stability is a priority
- You want to avoid vendor lock-in
- Your team has experience with traditional Java EE
- You're working in a highly regulated environment
- You need guaranteed backward compatibility.

Code example:

Here's a simple Hello world RESTful Example, using the Jakarta RESTful Web Service specification. You don't need to add additional dependencies. Just run it using a Jakarta EE compatible product that supports REST.

Conclusion

Most companies develop their enterprise applications in Java and with Jakarta EE platforms providing stability and backward-compatibility, it has become a reliant and relevant framework to use. So, whether you're a novice, intermediate or a senior Java developer and are keen to build an enterprise application, with a stable, robust and matured framework, with optimised runtimes that are Jakarta EE compatible runtimes, look no further than Jakarta EE specifications.

How to run Large Language Models (LLMs) locally.

Buhake Sindi — Fri, 07 Mar 2025 09:34:36 +0000

Whether you are a developer or an AI enthusiast, you might be glad to know that you can run Large Language Models locally.

Benefit of running LLM locally.

There might be various reasons to run LLMs locally:

Privacy: Running LLM locally ensures that sensitive data is controlled by the user, which might be a prerequisite requirement by data privacy regulators
1. Reduced Latency: Since data are not send to LLMs in the cloud, the response time are generally faster (assuming you're running it on good, strong hardware) as the response time are reduced compared to its cloud-based counterpart.
2. Cost efficiency: Should you have a decent hardware to run LLMs locally the cost of high usage costs are totally reduced.

This will require a good, capable hardware with enough storage space to run LLM locally.
If you're running it on a normal PC, you will need a GPU acceleration enabled PC to run it efficiently.

I'll highlight on popular tools that allows you to run LLMs locally. I've specifically chosen tools that allows developers to run the LLM as a local server so that they can code and run their AI agents locally via APIs. They can, then, switch back to cloud-based LLMs later (by changing the endpoint and providing their API keys).

For each of the tools, we'll download and play with the open-source DeepSeek R1 model.

Ollama with Chatbox AI client

Ollama is a lightweight tool designed to download open-source large language models (LLMs) directly on your computer. It also exposes an API to create, modify and/or provide a REST API for running and managing models too.

The Ollama library provides a list of models supported by Ollama.

Requirement: You should have at least 8 GB of RAM available to run the 7B models, 16 GB to run the 13B models, and 32 GB to run the 33B models.
Download: To download Ollama on your local PC on Windows, MacOS, Linux.
Source code: Ollama on GitHub.

Getting started.

Download and install the latest release of Ollama on your PC.
Download and install Chatbox AI client.
Once Ollama is fully installed, open the console, command line, PowerShell or terminal (depending on your operating system of choice). You will notice a white ollama "llama" logo installed on the notification tray if you're running it on Windows.
Enter the command ollama --help to see the available ollama commands.
Go to the Ollama library. Click on the model version tag (in our case 8b) and copy the any of the command of the model listed and paste it on your console/terminal on local machine: > ollama run deepseek-r1:8b
Once the download is complete, the model will be running locally. You will see the message >>> Send a message (/? for help) showing that the model is running.
To prompt the model from the command line/console, enter your message in double quotes. Example: > >>> "What model are you?" > <think> > > </think> > > Hi! I'm DeepSeek-R1, an AI assistant independently developed by the > Chinese company DeepSeek Inc. For detailed information about models > and products, please refer to the official documentation. > > >>> Send a message (/? for help) >
To terminate the model session on your command line/terminal, enter /bye.
Once you're running a model locally, open Chatbox AI client.
On settings (bottom left, select the OLLAMA API as the "Model Provider" and click "Save".
Select the deepseek-r1:8bmodel next to the blue send button.
Now, you can chat away! (where it says "Type your question here...") 😉

For developers: you can interface your installed LLM using an OpenAI client (base URI: http://localhost:11434 and model deepseek-r1:8b).

Jan.ai 👋

Jan is an open-source AI assistant that runs 100% offline, locally on your computer. It also uses a local API server (Cortex Server) to run an OpenAI-equivalent API locally.

Requirement: PC with Nvidia GPU support (for better performance).
Download: To download Jan.ai on your local PC on Windows, Linux and MacOS.
Source code: Jan.ai on GitHub.

Getting started.

Download and install the latest release of Jan.ai on your PC.
You will need to go to HuggingFace to select the model GGUF (GPT-Generated Unified Format) link. In this case, we'll use unsloth/DeepSeek-R1-GGUF link (https://huggingface.co/unsloth/DeepSeek-R1-Distill-Llama-8B-GGUF).
Open Jan, once it is installed. In settings (⚙), select "My Models" and paste the GGUF link on the search (🔍) bar and choose the model you wish to run.
Once the GGUF model download is complete, select "Thread", and select the downloaded model from the "Select a model" button.
Now, you can chat away! (where it says "Ask me anything") 😉

For developers: you can interface your installed LLM using an OpenAI client (base uri: https://localhost:1337).

LM Studio

LM Studio is an open-source, free desktop application designed to simplify the installation and usage of open-source Large Language Models (LLMs) locally on users' computers. The LM Studio GUI app is not open source. However LM Studio‘s CLI lms, Core SDK, and our MLX inferencing engine are all MIT licensed and open source. You can run any compatible Large Language Model (LLM) from Hugging Face, both in GGUF (llama.cpp) format, as well as in the MLX format (Mac only). You can run GGUF text embedding models. Some models might not be supported, while others might be too large to run on your machine. Image generation models are not yet supported.

You can also run an Open-AI like HTTP server on your local machine (localhost).

Requirement: if you have 16GB of RAM, you can run the 7B or 8B parameter distilled models. If you have ~192GB+ of RAM, you can run the full 671B parameter model.
Download: You can download LM Studio from here.

Getting started.

Download and install the latest release of LM Studio.
Select the Discover (🔍) on the sidebar and search for DeepSeek-R1 on the search bar. A list of all GGUF files will be displayed (it searches from HuggingFace for you).
Download the model that suits your PC requirements.
Once the model is complete, go to chat (💬) icon and select your DeepSeek-R1 model (top of the chat) and start asking away! 😉
For more details, you can read this blog here.

For developers: you can interface your installed LLM using an OpenAI client (base URI: http://localhost:1234/v1/).

Conclusion

There hasn't been a better time to start playing and experiencing LLMs without worrying about data privacy and the cost implications of cloud-based LLMs.

For developers and enthusiasts, using LLM locally can have practical applications, such as building AI agents, and be able to create custom/fine-tune models, all at a reduced cost.

Here's a list of South African Public APIs for all developers and enthusiasts

Buhake Sindi — Mon, 30 Dec 2024 22:26:26 +0000

I've decided to create and publish a database list of South African Public APIs for all developers and enthusiasts. Yes, you're welcome to contribute to the list.

Check it out.

Are software engineers actually engineers in South Africa?

Buhake Sindi — Thu, 01 Dec 2022 01:15:12 +0000

Note: This is also posted on my other blog site.

There's a recent event that shook the tech industry worldwide.

From this SlashDot News:

The Association of Professional Engineers and Geoscientists of Alberta
(APEGA), has asked a court to order one of the province's leading
software companies, Octopusapp, known as Jobber, to stop using the
term "engineer" in job titles and postings unless it gets a permit
from the regulator. That has caused an uproar in Alberta's tech
sector.

The full article can be found here.

To cut the story short, APEGA wants companies and individuals to stop using the titles "software engineer" and "computer engineer", unless individuals are licensed as engineers as "Professional engineers are held to high professional and ethical standards and work in the public interest", they said.

So, what does this mean in the South African tech industry? Are software engineers actually engineers?

In South Africa, the statutory body for engineering profession is called The Engineering Council of South Africa (ECSA). As their website states:

The Engineering Council of South Africa (ECSA) is a statutory body
established in terms of the Engineering Profession Act (EPA), 46 of

The ECSA's primary role is the regulation of the engineering profession in terms of this Act. Its core functions are the accreditation of engineering programmes, registration of persons as professionals in specified categories, and the regulation of the practice of registered persons.

According to the Engineering Profession Act (EPA), 46 of 2000, the focus of ECSA is to ensure that registered professionals in the engineering profession:

apply their knowledge and skill in the interest of humanity and the environment;
to execute their work with integrity and sincerity and in accordance with generally accepted norms of professional conduct; and
respect the interest of their fellow being and honour the standing of the Profession.

These are stipulated in the Code of Professional Conduct and this allows that the Registered person allow its conduct and ethics to be made subject to the scrutiny of its peers and the public.

A Professional Engineer with an accredited Engineering degree(s) - B.Eng or B.Sc(Eng) - that satisfies the educational requirement as a candidate of ECSA can register, and, only accredited from a recognised tertiary university in South Africa, recognised by ECSA can register.

Where does Software Engineering fit within the Engineering Profession, as defined by ECSA?

ECSA can consider candidates in the Software Engineering profession if the candidate has completed and obtained an accredited engineering - B.Eng/B.Sc(Eng) - type qualification from a recognised tertiary university in South Africa. Therefore, only those that have completed and obtained an accredited degree in Computer Engineering can be considered as candidate for Professional Engineer by ECSA.

The guideline for registration for Professional Engineer in Computer Engineering can be found here.

The Institute of Information Technology Professionals South Africa (IITPSA)

The Institute of Information Technology Professionals South Africa (IITPSA), formerly Computer Society of South Africa (CCSA), is a professinal body recognised by the South African Qualifications Authority (SAQA).

IITPSA's aims are:

to further the study, science and application of Information and Communications Technologies (ICTs);
maintain and promote Codes of Conduct and Ethics for our members;
define and promote standards of ICT knowledge; promote the formulation of effective policies on ICT and related matters;
and extend the knowledge and understanding and usage of ICTs in the community.

Thus, adherence to IITPSA’s Code of Conduct and Code of Practice assures others that IITPSA members are committed to ethical and professional behaviour.

Professional Software Engineers in the ICT (Information and Communications Technology) sector can become a Certified Member IITPSA (CMIITPSA).

Final thoughts?

Software is an increasingly critical component in many systems, some having huge social and commercial impact.

However, the question still remains: Should “Software Engineering” become a branch of engineering under the ECSA framework (if we want it to be recognsised as an engineering profession)?

There has been several efforts to create a curriculum for Software Engineering education. The IEEE Standard of 610.12-1990 (Software Engineering Terminology) was established by the IEEE Computer Society, which defines Software Engineering as:

The application of a systematic, disciplined, quantifiable approach to
the development, operation and maintenance of software; that is, the
application of engineering to software.

They have, even, established a Software Engineering Body of Knowledge (aka SWEBOK) - currently SWEBOK V3 is available for download - provides 5 objectives, some which can be considered as engineering principles:

To promote a consistent view of software engineering worldwide

To specify the scope of, and clarify the place of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics

To characterize the contents of the software engineering discipline

If Software Engineering be considered as a true engineering profession in SA, we would require that:

Software Engineering is formally listed at ECSA.
A formal, recognised accreditation, specific to Software Engineering qualification that meets the IEEE Computer Society Standard is taught by accredited tertiary institution.
Qualified Software Engineers formally register in order to satisfy the requirements to be a Professional Engineer in Software Engineering.

Thus, is software engineering actually an engineering activity? That is left for the reader to decide.

Microservice: Creating a JPA application using Jakarta Persistence API in Payara Micro

Buhake Sindi — Fri, 11 Feb 2022 01:51:02 +0000

In this blog we are going to discuss how your Java microservice application can connect to and interacts to relational database through the Jakarta Persistence API (latest version at time of writing is version 3.0). You can configure a data source and a JDBC driver so an application that is running on your Payara Micro server can connect with a relational database.

Before we begin...

This blog tutorial, we will configure this application with the following in mind:

The microservice application will be Mavenized Java application.
We will use MySQL DB Server as a relational database.
The JDBC datasource will be a transactional datasource (XADataSource).

JDBC Driver library configuration with Maven

In order for your Java application to connect with a relational database, you need a JDBC driver, which is typically provided by the database vendor. Fortunately, most database vendors have released their JDBC drivers to a Maven repository.

If you use Maven to build your application, you can add your JDBC driver by adding code that is similar to the following example to your pom.xml file.

    <dependencyManagement>
        <dependencies>
            <!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
                <version>8.0.19</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>
    </dependencies>

With Maven, the JDBC driver file will be copied to the WEB-INF/lib folder of your application WAR file during the package build phase.

Configuring a Database Datasource

In the Payara Blog a datasource is configured inside the web.xml file. In this example there is another alternative in creating a datasource configuration. The following example shows the basic pattern to configure a data source in your payara-resource.xml file inside the src/main/java/webapp/WEB-INF folder:

    <!DOCTYPE resources  PUBLIC  "-//Payara.fish//DTD Payara Server 4 Resource Definitions//EN"  "https://raw.githubusercontent.com/payara/Payara-Community-Documentation/master/docs/modules/ROOT/pages/schemas/payara-resources_1_6.dtd">
    <resources>
        <jdbc-resource pool-name="MyAppDS"
                       jndi-name="java:app/jdbc/MyApp"
                       enable="true"/>
        <jdbc-connection-pool name="MySQLPool"
                              res-type="javax.sql.XADataSource"
                              datasource-classname="com.mysql.cj.jdbc.MysqlXADataSource">
            <property name="url" value="jdbc:h2:mem:hibernateExample"/>
            <property name="User" value="testUser"></property>
            <property name="Password" value="testPassword"></property>
            <property name="DatabaseName" value="myapp_db"></property>
            <property name="ServerName" value="localhost"></property>
            <property name="PortNumber" value="3306"></property>
        </jdbc-connection-pool>
    </resources>

Application configuration for relational database connections

To use a data source that is configured in your payara-resource.xml file, you can either inject the data source or specify a lookup in your application code. The following examples assume that a jndi-name value of java:app/jdbc/MyApp is specified as the jdbc-resource element attribute in the payara-resource.xml file.

    @Resource(name= "java:app/jdbc/MyApp") 
    DataSource mySQLDatasource;

Injecting JPA EntityManager to your application

Once your datasource is configured in your payara-resource.xml file, we need to register your datasource inside the persistence.xml in your src/main/resources/META-INF/persistence.xml file. The jta-data-source is & matches the jndi-name of the datasource as specified in the payara-resource.xml.

    <?xml version="1.0" encoding="UTF-8"?>
    <persistence version="2.1"
        xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd ">
        <persistence-unit name="MyAppPU" transaction-type="JTA">
            <jta-data-source>java:app/jdbc/MyApp</jta-data-source>
            <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
            <properties>
                <!-- JBoss Wildfly's Hibernate 4 specific JPA properties -->
                <property name="hibernate.cache.use_second_level_cache" value="true" />
                <property name="hibernate.hbm2ddl.auto" value="validate" /><!-- NEVER: update -->
                <property name="hibernate.show_sql" value="false" />
                <property name="hibernate.format_sql" value="false"/>
                <property name="hibernate.use_sql_comments" value="false" />
                <property name="hibernate.enable_lazy_load_no_trans" value="true"/>
                <!--  For Performance monitoring on Hibernate -->
                <property name="hibernate.generate_statistics" value="false"/>
                <property name="hibernate.cache.use_structured_entries" value="false"/>

                <!-- TomEE PluME 1.7.2 and higher with EclipseLink  -->
                <property name="eclipselink.logging.logger" value="JavaLogger" />
            </properties>
        </persistence-unit>
    </persistence>

You can inject your EntityManager in your Java application code by specifying your persistence unit MyAppPU in your PersistenceContext annotation:

    @PersistenceContext(unitName="MyAppPU")
    private EntityManager entityManager;

In conclusion...

Although Payara Micro doesn't ship with an admin console (due to its lightweight platform) compared to Payara Server, it is still possible and simple enough to create JDBC Datasource in Payara Micro that can be used in your enterprise Java microservice application. In fact, with the power of Jakarta Persistent API you can write modern enterprise ORM that interacts with popular relational databases or interact directly once with your relational database by injecting a DataSource, even via a JNDI lookup too!

Understanding Jakarta EE 8 - C.D.I. (Part 3) - Defining custom CDI annotations.

Buhake Sindi — Sun, 18 Jul 2021 00:28:48 +0000

[As we continue with this series, we will refer to some content and examples from the CDI 2.x specification].

The CDI specification allows developers the flexibility to create new types that are within the scopes of the bean type declaration.
In this example we will examine and learn how easy it is to create custom CDI annotations for defining:

New qualifier types.
New Stereotypes.

Defining new qualifier types.

A qualifier type is a Java annotation defined as @Retention(RUNTIME). Typically a qualifier type is defined as @Target({METHOD, FIELD, PARAMETER, TYPE}).

Defining a qualifier type may be declared by specifying the @javax.inject.Qualifier meta-annotation.

In our example, we've created 2 service-defined qualifier types, @Jabbawockee and @LesTwins qualifiers.

@Qualifier
@Documented
@Retention(RUNTIME)
@Target({ TYPE, FIELD, METHOD, PARAMETER })
public @interface Jabbawockee {

}

@Qualifier
@Documented
@Retention(RUNTIME)
@Target({ TYPE, FIELD, METHOD, PARAMETER })
public @interface LesTwins {

}

And a bean is qualified by annotating the bean class or producer method or field with the qualifier type.

@Jabbawockee
public class JabbawockeeService implements Service {

    public void doWork() {
        System.out.println("Jabbawockee doing the work.");
    }
}

Stereotypes

The JavaEE specification specifies stereotypes as:

A stereotype is a kind of annotation, applied to a bean, that incorporates other annotations. Stereotypes can be particularly useful in large applications in which
you have a number of beans that perform similar functions.

A well-known stereotypes, known by Enterprise Java Developers, are from Spring Framework: @Component, @Service and @Repository stereotypes.

A stereotype is an annotation, annotated @Stereotype(@javax.enterprise.inject.Stereotype), that packages several other annotations. For instance, to recreate the 3 stereotypes from Spring Framework into your JavaEE application:

@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
@Documented
@Named
public @interface Component {}

Note that our Component stereotype has been declared with an empty @Named annotation, which specifies that every bean with the stereotype has a defaulted name when a name is not explicitly specified by the bean. A @Named qualifier declared by a stereotype is not added to the qualifiers of a bean with the stereotype.

If a stereotype declares a non-empty @Named annotation, the container automatically detects the problem and treats it as a definition error.

@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
@Component //Note that Spring specifies that this annotation is a specialization of Component annotation.
public @interface Service {}

@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Repository {}

Stereotype can be specified with interceptor bindings by annotating the stereotype with interceptor binding types. For example, to have a transactional business service, we can annotate our Service stereotype with @Transactional.

@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
@Transactional
@Component
public @interface Service {}

Also, the default scope of a stereotype is defined by annotating the stereotype with a scope type. A stereotype may declare at most one scope. If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error.

For example, in our Controller stereotype, we may specify to have a default @RequestScoped scope type:

@RequestScoped
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
@Documented
@Named
public @interface Component {}

Built-in stereotype.

The CDI framework provides us with a built-in stereotype @javax.enterprise.inject.Model which is intended for use with beans that define the model layer of an MVC web application architecture such as Jakarta Server Faces.

@Named
@RequestScoped
@Stereotype
@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface Model {}

In the next article, we will examine Producers (producer method and producer field), injecting using @Produces and Decorators, using the @Decorator annotation.

Understanding Jakarta EE 8 - C.D.I. (Part 2) - Qualifying your beans (continued…).

Buhake Sindi — Tue, 29 Dec 2020 23:11:31 +0000

[As we continue with this series, we will refer to some content and examples from the CDI 2.x specification].

Suppose that you have more than one implementation of a bean to certify a service contract or you have more than one version of a bean you use for different purposes, such as an alternative bean (mock) for testing purposes.

Instead of writing different codes for choice selection of your bean, bean selection choice can be done at deployment time using alternatives.

Defining Alternative Beans.

To make the bean available for lookup, injection or for EL resolution, annotate your bean using @Alternative anntations (FQN: javax.enterprise.inject.Alternative).

@Alternative
public class MockOrder extends Order { ... }

By default @Alternative beans are disabled. They are only activated for a specific bean archive by editing beans.xml. You can also have several beans that implement the same interface, all annotated @Alternative. In this case, you must specify in the beans.xml file which of these alternative beans you want to use. The alternatives that you specify in the beans.xml file apply only to classes in the same archive.

Using `@Priority` to specify alternatives.

To enable an alternative bean globally for an application, especially when it has multiple modules use the @javax.annotation.Priority annotation.

@Alternative
@Priority(100)
public class HighPriorityProcessor implements Processor { ... }

The alternative with higher priority value is selected if several alternative beans that implement the same interface are annotated with @Priority. You do not need to specify the alternative in the beans.xml file when you use the @Priority annotation.

Example 03: CDI injection of `@Alternative` bean (injection on interface, with 2 different implementations)

The tutorial source code can be found here and the running executable class file can be found here. The Service interface has 2 different implementation: DefaultService and AlternativeService (annotated with @Alternative).

The MainController injects a Service and without activating the AlternativeService, the DefaultService will be injected (as it's implicitly qualified as a @Default qualifier).

If we want to ensure that AlternativeService is injected inside MainController, we activate it inside beans.xml (source code can be found here).

    <alternatives>
        <class>za.co.sindi.tuts.jakartaee.cdi.example03.AlternativeService</class>
    </alternatives>

Running the DefaultCDIMain class, you will see the output Alternative Service work..

In the future tutorial we'll focus on @Stereotypes and how to apply factory methods in CDI.

Introducing Jakarta EE 9...

Buhake Sindi — Mon, 21 Dec 2020 00:15:32 +0000

Since Oracle's announcement that it would submit Java EE to the Eclipse Foundation the Java community has received 2 official Jakarta EE releases, the latest being Jakarta EE 9 (released on 22 November 2020).

So what can we look forward to with this release?

Objectives with Jakarta EE 9

The main objective of Jakarta EE 9 is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*. That's right: the old javax.* namespace has been replaced by the jakarta.* namespace. This makes it the very first official Jakarta EE release that is not reliant on the previous Oracle namespace.

Changes in Jakarta EE 9

With the shift of the Jakarta EE namespace, developers must be aware of changes and updates on the following:

Every API were transitioned from javax namespace to jakarta namesapce. This means that the Jakarta EE specification were changed to reflect the API changes as well as the implementation specification of the API were changed to handle the new APIs.
Jakarta EE 9 release removes specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs. Thus, CORBA implementations no longer exists in Jakarta EE 9. SOAP specifications are deemed stable. There won't be any future plans to work on the technology.
All specifications included in the Jakarta EE 9 release have been versioned to a new major version of the specification document. For example, JPA 2.x (in Jakarta EE 8) is now JPA 3.0 in Jakarta EE 9
No backward compatibility. Jakarta EE 9 is not backward compatible with Jakarta EE 8 or Java EE 8. It's not recommended to mix Jakarta EE 8 artifacts with Jakarta EE 9 and vice versa.

Migrating to Jakarta EE 9

Migrating to Jakarta EE 9 will require that developers/users must begin transitioning to Jakarta EE 9 compatible application servers. Currently, at the time of writing this post, Glassfish 6 supports Jakarta EE 9. Until other vendors release Jakarta EE 9 compatible products and applications servers, user migration and transitioning to Jakarta EE 9 might take a while. Note that this might be an expensive exercise to upgrade to Jakarta EE 9 so users must be aware of whether the rich feature set that comes Jakarta EE 9 is worth the upgrade.

For developers willing to start working with Jakarta EE 9 release, one needs to just update their pom.xml (if the project is Mavenized), by adding the following dependency:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>9.0.0</version>
    <scope>provided</scope>
</dependency>

And ensuring that they organise their import to change their namespace from javax to jakarta. Jakarta EE 9 is compatible with Java SE 8.

The Future of Jakarta EE (Jakarta EE 10 and beyond)

The future of Jakarta EE will be a much more exciting release for application developers than Jakarta EE 9 because the Eclipse Foundation encourages developers and the Java community to put their ideas forward so that features and functionality that we can help drive what technology to include (such as cloud-native technology, etc.) to help move Jakarta EE forward.

The best way is to join the Jakarta EE mailing list to start driving the discussion of Jakarta EE 10 forward.

Have you migrated to Jakarta EE 9 yet or are you planning to migrate to Jakarta EE 9? We look forward to continuing to see how this most recent update to Jakarta EE 9 will impact the Java community.

Understanding Jakarta EE 8 - C.D.I. (Part 2) - Qualifying your beans.

Buhake Sindi — Sun, 13 Dec 2020 01:41:01 +0000

[As we continue with this series, we will refer to some content and examples from the CDI 2.x specification].

In order for the CDI container to recognise your bean for injection, your bean needs to be qualified. This can be achieved by associating a bean with a qualifier type. A qualifier type represents some client-visible semantic associated with a type that is satisfied by some implementations of the type (and not by others). In other words, a qualifier type identifies a bean with a type that can be satisfied to one specific implementation of the same type (else it becomes an unsatisfied dependency).

Let's look at how a bean can be qualified using a bean qualifier types.

Bean Qualifier Types

There's 3 standard qualified types that are defined in the javax.enterprise.inject package:

@Any: Every bean has the built-in qualifier @Any, even if it does not explicitly declare this qualifier, except for the special @New.
@Default: If a bean does not explicitly declare a qualifier other than @Named, the bean has the qualifier @Default.
@New: The @New qualifier allows the application to obtain a new instance of a bean which is not bound to the declared scope, but has had dependency injection performed.

The following declarations are equivalent:

@Default
public class Order { ... }

public class Order { ... }

Both declarations result in a bean with two qualifiers: @Any and @Default.

The default qualifier is also assumed for any injection point that does not explicitly declare a qualifier, Thus, the following declarations, in which the use of the @Inject annotation identifies the constructor parameter as an injection point, are equivalent:

public class Order {
    @Inject
    public Order(@Default OrderProcessor processor) { ... }
}

public class Order {
    @Inject
    public Order(OrderProcessor processor) { ... }
}

In conclusion, the @Any and the @Default qualifier are always assumed during bean qualification as well as at injection point when the qualifier hasn't been explicitly declared.

The `@Named` Qualifier

The @Named is defined by the package javax.inject. This qualifier is used to specify the name of a bean. For example, this bean is named currentOrder:

@Named("currentOrder")
public class Order { ... }

The above declaration results in a bean with three qualifiers: @Any, @Default and @Named("currentOrder").

If @Named is declared by the bean with no bean name provided, the default bean name is used, after converting the first character of the class name to lowercase. For example, using the example above, if Order class was just annotated with @Named, the default bean name will be order.

For more information, please refer to section 3.1.5 Default bean name for a managed bean.

If @Named is not declared by the bean, nor by its stereotypes, a bean has no name.

Now that you have a basic insight on qualifying beans, let's look at various examples of qualifying beans using bean qualifier types. Note that we've set the bean-discovery-mode as all, the CDI container successfully recognised our classes as a qualified classes, ready for injection.

Example 1: CDI injection of implicit `@Default` bean class (with no interfaces)

The tutorial source code can be found here and the running executable class file can be found here and it follows the example as mentioned in the previous article. The DefautService and MainController classes are simple classes that don't extend nor inherit any other class or interfaces respectively and has not been annotated with any bean qualifiers. This is due to the fact that all qualified bean are implicitly set as @Any and @Default.

Example 2: CDI injection of implicit `@Default` bean class (injection on interface)

This is the extension of Example 1 but, in this case, the DefaultService implements the Service interface.
The tutorial source code can be found here and the running executable class file can be found here. On MainController class we simply inject on the property which links to the Service interface.
Seeing that there are no annotations on DefaultService, the CDI container has managed to successfully discovery one implementation of the Service interface and thus, creating a contextual context around the Service interface (which in turn will inject DefaultService when needed).
The DefaultService implicitly is qualified as a @Any and @Default.

Let's pause on here. In the next tutorial we'll look on how to tackle injections of classes / interfaces that can produce more than 1 dependency injections using @Alternative as well as defining our own custom qualifier type.

Forem: Buhake Sindi

Bring AI into your Jakarta EE apps with LangChain4J-CDI

What is LangChain4J-CDI?

Getting started with LangChain4J-CDI

1) Add dependencies (Maven)

2) Configure your model(s) with MicroProfile Config

3) Declare an AI Service interface

3.1) The @RegisterAiService annotation.

3.2) Your AI Service agent

3.3) Adding Memory

3.4) Adding Tools

3.5) RAG (Retrieval-Augmented Generation)

4) Inject and use it

4) Observability and resiliency.

4.1) Fault Tolerance using Microprofile Fault Tolerance.

4.2) Observability using Microprofile Telemetry

In Summary

Important Links

Introducing SmallRye LLM - Injecting Langchain4J AI Service for Java developers.

What is Langchain4J (simplified)?

Langchain4J Ai service

Langchain4J in enterprise Java

Introducing Langchain4J Microprofile with SmallRye-LLM.

Langchain4J Microprofile examples.

Building your own Langchain4J AI Service.

In Summary

Exciting news for Java developers

Why Java Developers Should Choose Jakarta EE / Microprofile Framework

Before we begin

The Jakarta EE framework.

Jakarta EE relevancy

Designed with innovations in mind

Specifications in Jakarta EE

Why choose Jakarta EE over other Java enterprise frameworks?

Code example:

Conclusion

How to run Large Language Models (LLMs) locally.

Benefit of running LLM locally.

Ollama with Chatbox AI client

Getting started.

Jan.ai 👋

Getting started.

LM Studio

Getting started.

Conclusion

Here's a list of South African Public APIs for all developers and enthusiasts

Are software engineers actually engineers in South Africa?

Where does Software Engineering fit within the Engineering Profession, as defined by ECSA?

The Institute of Information Technology Professionals South Africa (IITPSA)

Final thoughts?

Microservice: Creating a JPA application using Jakarta Persistence API in Payara Micro

Before we begin...

JDBC Driver library configuration with Maven

Configuring a Database Datasource

Application configuration for relational database connections

Injecting JPA EntityManager to your application

In conclusion...

Understanding Jakarta EE 8 - C.D.I. (Part 3) - Defining custom CDI annotations.

Defining new qualifier types.

Stereotypes

Built-in stereotype.

Understanding Jakarta EE 8 - C.D.I. (Part 2) - Qualifying your beans (continued…).

Defining Alternative Beans.

Using @Priority to specify alternatives.

Example 03: CDI injection of @Alternative bean (injection on interface, with 2 different implementations)

Introducing Jakarta EE 9...

Objectives with Jakarta EE 9

Changes in Jakarta EE 9

Migrating to Jakarta EE 9

The Future of Jakarta EE (Jakarta EE 10 and beyond)

Understanding Jakarta EE 8 - C.D.I. (Part 2) - Qualifying your beans.

Bean Qualifier Types

The @Named Qualifier

Example 1: CDI injection of implicit @Default bean class (with no interfaces)

Example 2: CDI injection of implicit @Default bean class (injection on interface)

Using `@Priority` to specify alternatives.

Example 03: CDI injection of `@Alternative` bean (injection on interface, with 2 different implementations)

The `@Named` Qualifier

Example 1: CDI injection of implicit `@Default` bean class (with no interfaces)

Example 2: CDI injection of implicit `@Default` bean class (injection on interface)