In my previous article, I discussed how Helidon integrates with LangChain4J. While the article provided a solid foundation, some readers pointed out the lack of a complete, hands-on example. This time, we’ll fix that by building a fully functional, practical AI-powered Java application.
We’ll create the Helidon Assistant — a chatbot with a web UI trained to answer questions about the Helidon framework. By “trained,” I mean it will be capable of answering questions based on the full Helidon documentation.
The rise of Large Language Models (LLMs) has opened new doors for AI-powered applications, enabling dynamic interactions, natural language processing, and retrieval-augmented generation (RAG). However, integrating these powerful models into Java applications can be challenging. This is where LangChain4J comes in – a framework designed to simplify AI development in Java.
To take things a step further, in version 4.2, Helidon introduced seamless LangChain4J integration, making it easier to build AI-driven applications while leveraging Helidon’s programming model and style. In this blog post, we’ll explore how this integration simplifies AI application development and how you can use it in your projects.
My previous article on migrating the Spring Petclinic Rest project to Helidon (see here) received a lot of positive feedback, which encouraged me to explore this area further.
The manual conversion process, while feasible, is time-consuming and requires careful attention to detail. However, it’s often more technical than creative—tedious, in other words. Automating this process would save time and reduce errors. While simple rule-based approaches (e.g., replacing <some Spring annotation> with <Helidon annotation>) can handle basic cases, they fall short for more complex conversions, such as transforming Spring REST Controllers to JAX-RS. This is where AI can help.
In this article, I’ll explain the approaches I took, the challenges I faced, and the results (spoiler alert: the results are very positive). I’ll start with a test project I created for the conversion.
The architecture of the Spring Petclinic Rest project
The architecture of the Helidon Petclinic project
How to migrate the data module
How to migrate REST controllers
How to write tests
Interesting issues and pitfalls, along with their solutions
Motivation
Initially, I anticipated the article would be short, but it ended up being quite lengthy. You could think of it as a missing chapter from the “Beginning Helidon” book I co-authored with my colleagues. Yes, it’s a bit cheesy to advertise the book in the first paragraph. You might assume that promoting the book was my sole motivation for writing this article. Admittedly, it’s a significant motivator, but not the only one.
In the Helidon support channels, we frequently encounter questions about migrating Spring Boot applications to Helidon. To address these inquiries, we concluded that creating a Helidon version of the well-known Spring Petclinic demo application and documenting the migration strategies and challenges would be the best approach. I volunteered for the task because of my previous experience with Spring programming and because I hadn’t engaged in real programming for quite some time, and I wanted to demonstrate that I still could. Whether I succeeded or not, you readers can decide after reviewing the work. Perhaps I shouldn’t have taken it on. You can find the result here. Anyway, enough philosophical musings; let’s get down to business.
The Jakarta EE Developer Survey is in its fourth year and is the industry’s largest open source developer survey. It’s open until April 30, 2021. I am encouraging you to add your voice. Why should you do it? Because Jakarta EE Working Group needs your feedback. We need to know the challenges you facing and suggestions you have about how to make Jakarta EE better.
Last year’s edition surveyed developers to gain on-the-ground understanding and insights into how Jakarta solutions are being built, as well as identifying developers’ top choices for architectures, technologies, and tools. The 2021 Jakarta EE Developer Survey is your chance to influence the direction of the Jakarta EE Working Group’s approach to cloud native enterprise Java.
The results from the 2021 survey will give software vendors, service providers, enterprises, and individual developers in the Jakarta ecosystem updated information about Jakarta solutions and service development trends and what they mean for their strategies and businesses. Additionally, the survey results also help the Jakarta community at the Eclipse Foundation better understand the top industry focus areas and priorities for future project releases.
A full report from based on the survey results will be made available to all participants.
The survey takes less than 10 minutes to complete. We look forward to your input. Take the survey now!
I am very pleased to announce that since the beginning of 2021 Oracle is officially a part of MicroProfile Working Group.
In Oracle we believe in standards and supporting them in our products. Standards are born in blood, toil, tears, and sweat. Standards are a result of collaboration of experts, vendors, customers and users. Standards bring the advantages of portability between different implementations that make standard-based solutions vendor-neutral.
We created Java EE which was the first enterprise Java standard. We opened it and moved it to the Eclipse Foundation to make its development truly open source and vendor neutral. Now we are joining MicroProfile which in the last few years has become a leading standard for cloud-native solutions.
We’ve been supporting MicroProfile for years before officially joining the Working Group. We created project Helidon which has supported MicroProfile APIs since MicroProfile version 1.1. Contributing to the evolution and supporting new versions of MicroProfile is one of our strategic goals.
I like the community driven and enjoyable approach of creating cloud-native APIs invented by MicroProfile. I believe that our collaboration will be effective and together we will push MicroProfile forward to a higher level.
I am proud to announce the Helidon 2.1.0 release. It’s a new minor release which introduces new features such as MicroProfile 3.3 support, new FaultTolerance implementation and @HelidonTest annotation, as well as bug fixes and performance improvements. The new version is available in Maven Central. See the full list of changes in the release notes.
You’ve decided that migrating a monolith application to a microservice is the best approach to meet new application needs. Microservices are cloud native, scalable, and can be created in different languages for different services.
When you’re ready to migrate, you can use different strategies. Among the most common is the strangler pattern, often used with the anti-corruption layer pattern. Both design patterns deserve careful consideration.
One major reason that many enterprises are thinking about migrating from monolith, on-premises applications to cloud native microservices is the cloud. The cloud provides many useful services, such as load balancers, monitoring and tracing tools, and auto-recovery—services that you’d have to implement and manage yourself if you didn’t use the cloud. Microservices are, in a way, designed for cloud, providing both scalability and portability. But should you convert your Java-based monolithic applications?
After almost a year of development, three milestones, and two release candidates, Helidon 2.0 is finally out of the development cage and ready for GA. Yay!
Dmitry's Technical Blog 