• Android Studio
• Aptana Studio
• Arachnoid
• Atom
• BBEdit
• BEA WebLogic Workshop
• BlueJ
• Borland JBuilder
• Brief
• Cloud9 IDE
• Codeanywhere
• Code::Blocks
• CodeWarrior
• Codenvy
• CodeLite
• CodeMix
• CodeRunner
• ConTEXT
• Crimson Editor
• DrJava
• Eclipse
• Eclipse Che
• EditPlus
• Emacs
• Ensime
• Geany
• Gedit
• Gitpod
• Greenfoot
• IBM Rational Application Developer
• IntelliJ IDEA
• JCreator
• JDEE (Java Development Environment for Emacs)
• jEdit
• jGRASP
• jMonkeyEngine SDK
• NetBeans
• Notepad++
• Oracle JDeveloper
• Processing
• PSPad
• SciTE
• SciTools Understand
• Spring Tool Suite (STS)
• Sublime Text
• SmartGit
• TextMate
• TextPad
• Together
• UltraEdit
• Vim
• Visual Studio
• Visual Studio Code
• Xcode
• XEmacs
• Zeus
• Microsoft Visual J++ (Historical)
• Symantec Visual Café (Historical)
• IBM VisualAge for Java (Historical)
• Sun Java Studio Creator (Historical)
• Sun Java Workshop (Historical)
• Sun Java Studio Enterprise (Historical)
• Forté for Java (Historical)
• Borland JBuilder (Historical)
• SuperCede (Historical)
• CodeWright (Historical)

In this article we will learn how to provision a WildFly Server using the JBang scripting tool. Starting from a basic example using a REST endpoint, we will show how to enable additional features on the application server with the WildFly Glow tooling. Why Run WildFly in your Java scripts? WildFly is an application server ... Read more

The post How to run WildFly applications with JBang appeared first on Mastertheboss.

Welcome to issue number two hundred and seventy-six of Hashtag Jakarta EE!

We are getting closer and closer to finalizing the refactoring of the Jakarta EE Platform TCK. The goal right now is to have the Jakarta EE 11 Platform ready for release review by the end of May 2025. Stay tuned for updates.

Plan reviews for Jakarta EE 12 are going on as we speak. Check out the progress in the Jakarta EE 12 Plan Review status board. My guess is that we will see quite a few more coming forward as the April 15 deadline is fast approaching.

The 2025 Jakarta EE Developer Survey is ongoing. If you haven’t done it yet, please respond to help us shape the evolution of Jakarta EE. It is important for us to gather the perspective from a diverse audience, so we have made the survey available in multiple languages, including  English, Spanish, Portuguese, Japanese, and Chinese.

Participate Today!

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

If you’re working with Jakarta EE — or just starting to explore the power of enterprise Java — there’s never been a better time to level up your skills. Whether you’re building your first servlet, designing secure REST APIs, or diving deep into dependency injection, the Jakarta EE community has been busy crafting an outstanding collection of starter and specification guides to help you get up to speed.

At Omnifish, we’re proud supporters of the open-source enterprise Java ecosystem, and we’re constantly pointing developers toward the best resources. So we’ve gathered up some of the most practical and insightful Jakarta EE guides to help you go from “Hello, World” to production-ready applications with confidence.

Let’s dive in.

Getting Started with Jakarta EE

Before building complex enterprise apps, it’s important to get the basics right. These starter guides will help you build a solid foundation — with real code examples and clear explanations.

1. How to Start with Servlets

The humble Servlet is at the heart of Jakarta EE. If you’re new to the platform or just need a refresher, this guide walks you through creating and deploying a basic servlet, handling requests and responses, and understanding the servlet lifecycle.

2. How to

The post Supercharge Your Jakarta EE Skills with These Must-Read Guides appeared first on OmniFish - Modern Jakarta EE Runtimes.

The Jakarta EE 11 Web Profile has officially been released on March 30, 2025 — bringing a cleaner, more modern baseline to the Jakarta EE platform, with strong alignment to recent Java versions, improved modularity, and the removal of legacy specifications.

Although it comes later than planned, due to unexpected challenges in refactoring the Jakarta EE TCK (compatibility kit), this release marks a key shift toward a more cloud-native, developer-focused platform — and we’re proud to say that Eclipse GlassFish was the first implementation to pass the Jakarta EE 11 Web Profile TCK and enable the specification’s final approval.

Key Technical Changes in Jakarta EE 11 Web Profile

Jakarta EE 11 Web Profile delivers an updated and streamlined set of specifications designed for lightweight, server-side Java applications. Major technical highlights include:

• Modern Java compatibility: Baseline raised to support newer Java LTS versions, including records (Java 17 supported, Java 21 recommended)
• CDI as a central integration model: Even deeper CDI integration across multiple specs
• Jakarta Data 1.0: A new spec in Jakarta EE; sets the stage for data access innovation
• Several specifications updated:
  • Persistence 3.2 – Java SE Records as embeddable classes, more functions in queries, Instant and Year support for date/time fields, and many more
  • Concurrency

The post Jakarta EE 11 Web Profile released, enabled by Eclipse GlassFish appeared first on OmniFish - Modern Jakarta EE Runtimes.

Welcome to issue number two hundred and seventy-five of Hashtag Jakarta EE!

Jakarta EE 11 Web Profile is released! It’s a little later than planned, but we’re finally there, and Jakarta EE 11 Web Profile joins Jakarta EE 11 Core Profile among the released specifications. It has been a tremendous effort to refactor the TCK.

Eclipse GlassFish was used as the ratifying compatible implementation of Jakarta EE 11 Web Profile. It would expect other implementations, such as Open Liberty, WildFly, Payara, and more to follow suit over the next weeks and months. Check out the expanding list of Compatible Products of Jakarta EE 11.

JavaLand 2025 happened last week. You can read about it in my blog post from the event. I will now be at home for the next couple of weeks before traveling to Bangalore, India for the Great International Developer Summit (GIDS).

Not too long ago, I upgraded my computer and got a new Lenovo ThinkPad X1 Carbon (a great machine so far!).

Since I was accustomed to working on a gaming rig (Ryzen 7, 64GB RAM, 4TB) that I had set up about five years ago, I completely missed the Secure Boot and TPM trends—these weren’t relevant for my fixed workstation.

However, my goal with this new laptop is to work with both Linux and Windows on the go, making encryption mandatory. As a non-expert Windows user, I enabled encryption via BitLocker on Windows 11, which worked perfectly... until it didn’t.

The Issue with Secure Boot and VirtualBox/VMware

This week, I discovered that BitLocker leverages TPM (the encryption chip) and Secure Boot if they’re enabled during encryption. While this is beneficial for Windows users, it created an unexpected problem for me: virtualization on Linux.

Let me explain. Secure Boot is:

...an enhancement of the security of the pre-boot process of a UEFI system. When enabled, the UEFI firmware verifies the signature of every component used in the boot process. This results in boot files that are easily readable but tamper-evident.

This means components like the kernel, kernel modules, and firmware must be signed with a recognized signature, which must be installed on the computer.

This creates a tricky situation for Linux because virtualization software like VMware or VirtualBox typically compiles kernel modules on the user’s machine. These modules are unsigned by default, leading to errors when loading them:

# modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by service

A good way to diagnose this is to check dmesg for messages like:

[47921.605346] Loading of unsigned module is rejected
[47921.664572] Loading of unsigned module is rejected
[47932.035014] Loading of unsigned module is rejected
[47932.056838] Loading of unsigned module is rejected
[47947.224484] Loading of unsigned module is rejected
[47947.257641] Loading of unsigned module is rejected
[48291.102147] Loading of unsigned module is rejected

How to Fix the Issue with VirtualBox Using RPMFusion and Akmods

Oracle is aware of this issue, but their documentation is lacking. To quote:

If you are running on a system using UEFI (Unified Extensible Firmware Interface) Secure Boot, you may need to sign the following kernel modules before you can load them: vboxdrv, vboxnetadp, vboxnetflt, vboxpci. See your system documentation for details of the kernel module signing process.

Fedora’s documentation is sparse, so I spent a lot of time researching manual kernel module signing (Fedora docs) and following user guides until I discovered that VirtualBox is available in RPMFusion with akmods support.

Some definitions:

1. RPM Fusion is a community repository for Enterprise Linux (Fedora, RHEL, etc.) that provides packages not included in official distributions.
2. Akmds automates the process of building and signing kernel modules.

Here’s the step-by-step solution:

1. Enable RPM Fusion (Free Repo)

Install the RPM Fusion free repository:

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

2. Install VirtualBox (with Akmods)

Ensure VirtualBox is installed from RPMFusion (akmods will be a dependency):

sudo dnf install virtualbox

3. Start Akmods to Generate Keys

Akmods will automatically sign the modules with a key stored in /etc/pki/akmods/certs:

sudo systemctl start akmods.service

4. Enroll the Key with Mokutil

Use mokutil to register the key in Secure Boot:

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

You’ll be prompted for a case-sensitive password—remember it for the next step.

5. Reboot and Enroll the Key

After rebooting, the UEFI firmware will prompt you to enroll the new key.

If needed, you could also check for the key contents in that screen.

6. Start VirtualBox Kernel Modules

The modules are now signed and can be loaded. Enable these at boot:

sudo systemctl start vboxdrv
sudo systemctl enable vboxdrv

Verify they’re loaded:

lsmod | grep vbox

Output:

vboxnetadp             32768  0
vboxnetflt             40960  0
vboxdrv               708608  2 vboxnetadp,vboxnetflt

Now, VirtualBox runs on Fedora with Secure Boot and TPM enabled, without disabling BitLocker on Windows.

Introduction

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.

What is LangChain4J?

LangChain4J is a Java framework that facilitates building AI-powered applications using LLMs from providers like OpenAI, Cohere, Hugging Face, and others. It provides:

• AI Services: A declarative and type-safe API to interact with models.
• Retrieval-Augmented Generation (RAG): Enhancing responses with external knowledge sources.
• Embeddings and Knowledge Retrieval: Working with vector-based search systems.
• Memory and Context: Managing conversational memory for intelligent interactions.

However, integrating LangChain4J manually into an application requires configuring components, managing dependencies, and handling injections manually. This is where Helidon’s integration module provides significant advantages.

How Helidon Simplifies LangChain4J Integration

Before we proceed, note that Helidon’s LangChain4J integration is a preview feature in Helidon 4.2. This means that while it’s production-ready, the Helidon team reserves the right to modify APIs in minor versions.

Helidon’s LangChain4J integration introduces:

• Helidon Inject Support: LangChain4J components are automatically created and registered in the Helidon service registry based on configuration.
• Convention Over Configuration: Reduces boilerplate by using sensible defaults.
• Declarative AI Services: Uses annotations to define AI services in a clean, structured manner.
• CDI Integration: Components work seamlessly in Helidon MP.

These features significantly reduce the complexity of incorporating AI into Helidon applications.

Setting Up LangChain4J in Helidon

To use LangChain4J with Helidon, add the following dependency to your Maven project:

<dependency>
    <groupId>io.helidon.integrations.langchain4j</groupId>
    <artifactId>helidon-integrations-langchain4j</artifactId>
</dependency>

Include the necessary annotation processors in the <build><plugins> section of your pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <annotationProcessorPaths>
            <path>
                <groupId>io.helidon.codegen</groupId>
                <artifactId>helidon-codegen-apt</artifactId>
            </path>
            <path>
                <groupId>io.helidon.integrations.langchain4j</groupId>
                <artifactId>helidon-integrations-langchain4j-codegen</artifactId>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

Using different LLM providers may require additional dependencies. For example, using OpenAI models requires adding a dependency to the OpenAI provider, while using Ollama requires adding the Ollama provider. This modular approach helps keep applications lightweight. For more information about providers and dependencies, refer to the documentation.

Creating AI Components in Helidon

When I refer to AI components, I mean the public API classes provided by LangChain4J. Examples include various models such as OpenAiChatModel and OllamaChatModel, embedding stores like InMemoryEmbeddingStore, content retrievers such as EmbeddingStoreContentRetriever, and ingestors like EmbeddingStoreIngestor, among others.

Some components are natively supported by the Helidon LangChain4J integration and can be automatically created when the corresponding configuration is present. The currently supported components include:

• LangChain4J Core
  • EmbeddingStoreContentRetriever
  • MessageWindowChatMemory
• Open AI
  • OpenAiChatModel
  • OpenAiStreamingChatModel
  • OpenAiEmbeddingModel
  • OpenAiImageModel
  • OpenAiLanguageModel
  • OpenAiModerationModel
• Ollama
  • OllamaChatModel
  • OllamaStreamingChatModel
  • OllamaEmbeddingModel
  • OllamaLanguageModel
• Cohere
  • CohereEmbeddingModel
  • CohereScoringModel
• Oracle
  • OracleEmbeddingStore

For example, the OpenAI chat model can be automatically created by defining the following configuration in application.yaml:

langchain4j:
  open-ai:
    chat-model:
      enabled: true
      api-key: "demo"
      model-name: "gpt-4o-mini"

With this configuration, an instance of OpenAiChatModel is automatically created and can be injected into other application components.

A key element in this setup is the enabled property. The component is only created if this property is set to true. This provides an easy way to disable component creation while retaining its configuration in the file for future use.

If you need to create a component that is not in the list above and register it in the Helidon service registry, you can use a Supplier Factory:

@Service.Singleton
@Service.Named("MyChatModel")
class ChatModelFactory implements Supplier<ChatLanguageModel> {
    @Override
    public ChatLanguageModel get() {
        return OpenAiChatModel.builder()
                .apiKey("demo")
                .build();
    }
}

This method allows you to register custom embedding models and other AI components dynamically. Service.Named("MyChatModel") annotation is optional. You can add it to define a name for your component for future reference.

Using AI Components

Helidon Inject makes it easy to use AI components within your application:

@Service.Singleton
public class MyService {
    private final ChatLanguageModel chatModel;

    @Service.Inject
    public MyService(ChatLanguageModel chatModel) {
        this.chatModel = chatModel;
    }
}

For named components, use:

@Service.Inject
public MyService(@Service.Named("MyChatModel") ChatLanguageModel chatModel) {
    this.chatModel = chatModel;
}

Alternatively, you can manually retrieve a component from the service registry as follows:

var chatModel = Services.get(OpenAiChatModel.class);

AI Services

Most often AI-powered components require a combination of different components working together. For example, a simple chat assistant requires a chat model to communicate with users, embedding store to store data, embedding model to retrieve and query the data, chat memory for keeping conversation context, etc. LangChain4J AI Services provide a way of combining different kinds of AI functionality behind a simple API which significantly reduces the boilerplate code.

Helidon’s LangChain4J integration introduces a declarative Helidon Inject-based approach for creating AI Services. It supports the following components:

• Chat Model:
  • dev.langchain4j.model.chat.ChatLanguageModel
• Streaming Chat Model:
  • dev.langchain4j.model.chat.StreamingChatLanguageModel
• Chat Memory:
  • dev.langchain4j.memory.ChatMemory
• Chat Memory Provider:
  • dev.langchain4j.memory.chat.ChatMemoryProvider
• Moderation Model:
  • dev.langchain4j.model.moderation.ModerationModel
• RAG:
  • Content Retriever: dev.langchain4j.rag.content.retriever.ContentRetriever
  • Retrieval Augmentor: dev.langchain4j.rag.RetrievalAugmentor
• Callback Functions:
  • Methods annotated with dev.langchain4j.agent.tool.Tool

Helidon makes it simple to define AI services using annotations:

@Ai.Service
public interface ChatAiService {
    String chat(String question);
}

In this scenario all LangChain4J components from the list above are taken from the service registry. User still has an ability to manually control the process by putting any of the following annotations which specify a service name which must be used for this particular function instead of discovering it automatically.

For example, in the snippet below a service with name “MyChatModel” will be used as chat model and all other components are discovered automatically.

@Ai.Service
@Ai.ChatModel("MyChatModel")
public interface ChatAiService {
    String chat(String question);
}

There is a possibility to switch off automatic discovery by using @Ai.Service(autodicovery=false). In this case the service components are not discovered automatically and users must add components manually using annotations specified above. @ChatModel or @StreamingChatModel annotations are required.

Tools: Enhancing AI with Custom Logic

LangChain4J tools enable AI models to invoke external functions during execution. This is useful when an LLM needs to perform an action during its conversation with a user, such as retrieving data, calling an external service, or executing code.

LangChain4J provides the @Tool annotation, which, when applied to a method, makes that method accessible for the LLM to call. The integration code scans the project for classes containing @Tool-annotated methods and automatically adds them to AI Services. The only requirement is that these classes must be Helidon Inject services.

@Service.Singleton
public class OrderService {
    @Tool("Get order details for specified order number")
    public Order getOrderDetails(String orderNumber) {
        // Business logic here
    }
}

If you are using Helidon MP, an additional step is required. You must annotate the service containing tools with the @Ai.Tool annotation. Additionally, the integration supports tools within CDI beans.

Samples

We have created several sample applications for you to explore. These samples demonstrate all aspects of using LangChain4J in Helidon applications.

Coffee Shop Assistant

The Coffee Shop Assistant is a demo application that showcases how to build an AI-powered assistant for a coffee shop. This assistant can answer questions about the menu, provide recommendations, and create orders. It utilizes an embedding store initialized from a JSON file.

Key features:

• Integration with OpenAI chat models
• Utilization of embedding models, an embedding store, an ingestor, and a content retriever
• Helidon Inject for dependency injection
• Embedding store initialization from a JSON file
• Support for callback functions to enhance interactions

Check it out:

• Coffee Shop Assistant for Helidon SE
• Coffee Shop Assistant for Helidon MP

Hands-on Lab

We also offer a Hands-on Lab with step-by-step instructions on how to build the Coffee Shop Assistant:

• HOL: Building AI-Powered Applications with Helidon and LangChain4J

Useful Resources

Ready to get started? Here are some useful resources:

• Helidon LangChain4J documentation
• LangChain4J documentation
• Helidon Inject documentation

Devnexus 2025 will be held Tuesday-Thursday, March 4-6, 2025 at the Georgia World Congress Center in Atlanta, Georgia. Members of the Jakarta EE Ambassadors will be in attendance to deliver presentations on Jakarta EE.

On March 4, developers will be able to choose from five workshops:

AI-Driven Development: Enhancing Java with the latest AI Innovations by Brian Benz

Developer to Architect by Nate Schutta

Migration Engineering with OpenRewrite: The Recipe for Success by Jonathan Schneider

Practical AI Lab for Enterprise Java Developers: From Zero to Hero by Daniel Oh, Eric Deandrea and James Falkner

Stream Processing As You’ve Never Seen Before (Seriously): Apache Flink for Java Developers by Viktor Gamov and Sandon Jacobs

Concurrent with the workshops are two summits for Java User Group leaders and Java Champions as they discuss issues that affect their respective Java User Groups and the roles of a Java Champion within the Java community.

On March 5-6, developers can expect many sessions on topics such as, AI, Architecture, Jakarta EE and Core Java (among many others).

The Jakarta EE track, in particular,  includes 10 sessions, namely:

A Developer’s Guide to Jakarta EE 11 by Michael Redlich

AI Tools for Jakarta EE by Gaurav Gupta

Foundations of Modern Java Server Apps by Kito Mann

Java + LLMs: A hands-on guide to building LLM Apps in Java with JakartaEE by Bazlur Rahman and Shaaf Syed

Migrating from Java EE – to Spring Boot or something else? by Ondro Mihályi

Jakarta EE meets AI: Beyond the chatbot with LangChain4j by Jorge CajasDuke on CRaC with Jakarta EE by Ivar Grimstad and Rustam Mehmandarov

Concurrency redefined: what’s new in Jakarta Concurrency 3.1 by Chuck Bridgham and Harry Hoots III

Jakarta EE: Connected Industries with an Edge by Petr Aubrecht

Case Study: Journey to Cloud with Jakarta EE and MicroProfile by Julian Ortiz

Developers can also expect keynote addresses throughout the conference and peruse the vendors that will display their wares. The Eclipse Foundation will also have a booth where folks from the Java community involved in Jakarta EE and MicroProfile will be on hand for conversation and for example applications that demonstrate new features offered in Jakarta EE 11.

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.

Test Project for Conversion

Initially, I considered using Spring Petclinic Rest as the target project. However, I found it too large and slow to process while iteratively testing my approach. Additionally, it includes components like multiple data layers for different databases, which add unnecessary complexity and offer limited value for the converter’s development. To address this, I created a custom test project called Spring Pets.

Spring Pets is a streamlined version of Spring Petclinic Rest, where the “clinic” aspect has been removed, and the design has been simplified. Despite its smaller scale, Spring Pets retains the essential functionality required for thorough testing of the conversion process, including:

• Spring Data JPA with HSQL database
• Spring Transactions
• Bean Validation
• Layered Design with three layers
• Spring REST Controllers
• MapStruct Mappers
• Jackson JSON Binding
• Spring MockMVC-based Tests

This project provides a balanced combination of simplicity and completeness, making it an ideal candidate for evaluating the AI-driven conversion process.

Conversion Results

Before diving into the technical aspects of the conversion, I want to share the results upfront, so you don’t have to scroll to the bottom to find them. After all, that’s likely the most interesting part of the article.

I successfully converted the entire Spring Pets project (excluding tests) using the incremental approach, which I explain below. I was able to compile the project after commenting out some dependencies in pom.xml.

The scope of the conversion:

• Three Spring Data JPA interfaces were implemented using CDI and JPA.
• Three Spring REST Controllers were converted to JAX-RS resources.
• One Spring service layer bean was converted to a CDI bean.
• Spring Boot pom.xml was converted to Helidon MP pom.xml.
• Six JPA Entities, three MapStruct mappers, and three DTOs were converted with minimal changes.

The conversion process took about 10 minutes using the OpenAI GPT-4o model. How long would it take manually? Ten times more? Twenty? More?

It’s definitely a time-saver.

The Conversion Process

Choosing a Model

Working with AI models is similar to working with developers. If the developer is experienced, you don’t need to explain every detail—just say “go ahead and do it.” For less experienced developers, you need to provide more explanation.

Better models produce better results and require less effort in explaining the task.

After trying several models, I ultimately settled on OpenAI GPT-4o, which produced the best results. The tradeoff is that it can be expensive, as each iteration costs a few cents. As an alternative, I also used OpenAI GPT-4o-mini, which is less expensive and produces acceptable results. It’s also possible to use locally hosted models, but the ones I tried produced worse results than GPT models and required more refined prompts. However, they are free.

Now, let’s dive into the conversion approaches.

Conversion Approaches

I considered several ways to approach the task of converting a Spring project to Helidon. I looked at the project as a whole to understand its technologies, then identified Helidon equivalents for those technologies. From there, I began converting files one by one, starting with those that had no dependencies on others.

How could I make AI handle this process? I came up with three approaches:

1. Contextual Conversion
   “Hey, AI! Here’s my project—go ahead and convert everything. Here are some general instructions and tools to read and write files.”
2. Incremental Conversion
   “Hey, AI! I’ll give you files one by one. First, you need to identify the file type, and then I’ll give you detailed instructions on how to convert it.”
3. Hybrid
   “Hey, AI! I’ll give you files one by one. First, you need to identify the file type, and then I’ll give you detailed instructions on how to convert it. I’ll also provide tools to access other project files that you can use during the conversion.”

The key difference between these approaches is how much control the model has and how much project context it retains. The contextual approach assumes the model has access to the entire project context and can work with all project files in any order. The incremental approach, on the other hand, provides less context but gives the model detailed instructions for each individual file. The hybrid approach combines aspects of both the contextual and incremental approaches. While it could theoretically offer the best results, I haven’t experimented with it yet, so it’s not covered in this article.

Approach 1: Contextual Conversion

The first approach I tried was to provide the model with the entire project context and let it determine the best way to convert everything. This process involves a single prompt with general instructions and a set of callback functions to access the project.

Theoretically, this approach allows flexibility in changing the project structure and adding or removing files.

You can check out the GitHub project for the converter here.

At first, it worked well, and my initial reaction was, “Wow!” However, as with many things, the devil is in the details. There were small errors, and fixing them made the prompt increasingly larger. Eventually, I realized that I was detailing the conversion process for specific file types, which led me to consider a more effective approach: processing files individually.

This approach is resource-intensive. With GPT-4o, each conversion attempt costs about 15 cents, and tokens per minute (TPM) limits are often exceeded, requiring timeouts. This was one of the main reasons I created the smaller Spring Pets project for testing.

I also struggled to make this work with locally hosted models, despite trying several options without success.

Pros:

• Provides a comprehensive understanding of the project context.
• Allows for changes in project structure.
• Supports the addition and removal of project files.

Cons:

• High resource consumption.
• Long processing times.
• Local models are insufficient for handling this complexity.

My conclusion is that GPT-4 is not yet sophisticated enough for this approach, but as AI models continue to evolve, this method may become more viable in the future.

Approach 2: Incremental Conversion

In this approach, each file is processed independently, without retaining context across files. It involves two steps:

1. Identify the file type.
2. Use a prompt with conversion instructions for that file type and pass it to the model along with the file.

I developed a converter based on this method. You can explore it on GitHub.

Initially, I considered building a dependency graph and using topological sorting to create a list of files, starting with those that had no dependencies. For each file, I used JavaParser to analyze and detect its type e.g., Rest controller, Spring Data repository etc. Ultimately, I switched to using AI for file-type identification, as it was simpler and more effective. Using a prompt, I asked the model to return a file type string based on the following criteria:

Classify the file based on the following criteria:

1. POM_XML: File name is `pom.xml`.
2. REST_CONTROLLER: Java class annotated with @RestController.
3. REPOSITORY: Java interface or class annotated with @RepositoryDefinition or extending Repository/CrudRepository.
4. ENTITY: Java class annotated with @Entity, @MappedSuperclass, @Table, or @Id.
5. SPRING_BEAN: Java class annotated with @Service, @Component, @Bean, or @Configuration.
6. PLAIN_JAVA: Java class, interface, or record that doesn't meet any other criteria.
7. UNIDENTIFIED: File is not a Java file or doesn't match any of the above criteria.

Output only the classification (one of the above).

This approach works well with different models, with minimal tuning required. Since the classification logic is externalized, it can be updated without recompiling the converter.

After identifying the file type, the converter reads a corresponding prompt (e.g., prompt_<file-type>.txt) and passes it to the model along with the file to convert, saving the result to disk.

This method works well with locally hosted models. I tested it with Qwen Coder in LM Studio. While functional, the results are not as good as those from OpenAI’s GPT models.

Pros:

• Lower resource requirements.
• Compatible with local models.
• Good conversion results.

Cons:

• Inability to add or delete files.
• Intensive prompts.

In conclusion, even without passing the entire project context, this approach outperforms the contextual one. It is more cost-effective, delivers better results, and is easier to customize. However, as models advance, the contextual approach may eventually become the preferred method.

Approach 3: Hybrid Approach

The Hybrid Approach combines elements of both the contextual and incremental approaches. I envision it as an incremental process with tools to provide project context. Although I have not experimented with this approach yet, it should theoretically combine the benefits and challenges of the other methods. While it could offer more versatility, it would also be more resource-intensive, expensive, and require advanced models.

Challenges

Working with AI is both fascinating and challenging. Unlike traditional programming, where the outcome depends on your development skills, AI-driven projects also require the ability to communicate effectively with the model and define tasks clearly. Writing prompts that the model can understand is essential.

One key to success is crafting precise, direct, and non-overlapping instructions in your prompts. However, things can get tricky. For example, I encountered an issue where the converted Java file was returned inside a Markdown formatting block, even though I had explicitly instructed the model to return only the raw file. I solved this by specifying the exact formatting string that should not be present. This felt like extra overhead.

Models are not deterministic. They may return different results for the same prompt and file, although this does not happen often. In most cases (95%), the conversion is great, but in the remaining 5%, issues like the unwanted Markdown formatting appear. This can be minimized or fixed by refining your prompts, though it is often difficult to pinpoint exactly how. Experimentation is key.

Prompts are not universal. Different models require different approaches. More advanced models need fewer explanations, while less sophisticated ones require more detailed instructions. It’s like working with developers at different skill levels.

Advanced models are like senior developers and therefore expensive. While they produce better results with less effort, they come at a higher cost. For instance, one attempt to convert Spring Pets using the contextual approach with GPT-4o costs about 15 cents. While not prohibitive, the costs add up with multiple runs. I ran the converter over 100 times, and processing larger projects will be even more expensive. Moreover, there are limits. I frequently reached the tokens per minute (TPM) limit, requiring timeouts. Paying more to OpenAI can lift these limits, but if you want the best results, be prepared to pay more.

Finally, legal considerations are also important. Always read the licensing agreements for the models you use to avoid potential legal issues. Some models may prohibit commercial use, and hosted models may process your data in ways that could violate intellectual property rights. Before using AI in commercial projects, always consult with legal experts.

Conclusion

AI is undoubtedly becoming a core part of our lives, transforming how we approach programming. The once-complex task of converting a project from one framework to another is now much easier with the help of AI, saving time and resources, making it highly cost-effective.

However, such converters are not limited to just Spring-to-Helidon conversions. Given the appropriate set of prompts, they can also assist in converting and migrating older javax.*-based Java EE projects to modern Jakarta EE.

I plan to continue improving the converters. As always, I welcome your feedback, whether in comments or on social media.

Here are the links to the GitHub projects mentioned in this article:

• Spring Pets – A test project used for conversion testing
• Contextual Converter
• Incremental Converter

Thank you!

We’re excited to announce that accounts.eclipse.org will migrate from Drupal 7 to Drupal 10 on January 19, 2025. This is a significant milestone in our ongoing effort to modernize the Eclipse Foundation’s web infrastructure, following the successful migration of the Project Management Infrastructure (PMI) earlier this year. This migration aligns with our plans that we outlined in last year’s post, Navigating the Shift From Drupal 7 to Drupal 9/10 at the Eclipse Foundation.

To ensure a smooth transition, we’ve scheduled a maintenance window on January 19, 2025, from 02:00 am CET to 06:30 pm CET, during which accounts.eclipse.org will be in read-only mode.

During this period, users will be able to log in and access other Eclipse Foundation websites, such as projects.eclipse.org, gitlab.eclipse.org, and marketplace.eclipse.org. However, some functionality, such as the profile edit form and the create an account form will be temporarily disabled to prevent data loss while we migrate your profile data to a new database.

We’re excited about this migration and hope it will provide a better user experience for all. If you have any feedback or encounter issues, please visit our dedicated issue, which includes details on how to access the staging environment to preview the changes and how to share feedback with us!

As part of our migration to Drupal 10, we’ve decided to discontinue support for Gravatar on sites such as accounts.eclipse.org, projects.eclipse.org, blogs.eclipse.org, marketplace.eclipse.org, and newsroom.eclipse.org. This change enhances privacy compliance by giving users more control over their data and ensures a more consistent experience across many of our web properties.

Why Are We Dropping Gravatar?

• Improved Privacy: Moving away from Gravatar reduces reliance on external services, giving users greater control over their profile pictures and personal data.
• Inconsistent Profile Pictures: Users have experienced issues in the past with their profile pictures displaying inconsistently across some sites due to syncing problems between Gravatar and our internal systems. This update ensures a more consistent experience.
• Lack of Support with Drupal 10: The Gravatar integration module used with Drupal 7 is not compatible with Drupal 10, and maintaining support would require significant effort.

What Does This Mean for You?

To address these issues, we’ve introduced a new profile picture endpoint that ensures a consistent solution for displaying profile pictures across supported sites. This endpoint will show either the user’s uploaded picture or our default silhouette if no picture is available. This update also aligns with our goal to minimise personal data that we need to sync across our various web properties.

To display a community member’s profile picture on your project website, simply replace [:eclipse_username] with the user’s Eclipse username and use that URL as the href value in your image tag:

https://accounts.eclipse.org/user/[:eclipse_username]/picture

For example, my picture is available here (my Eclipse username is “cguindon”):
https://accounts.eclipse.org/user/cguindon/picture

The content of that image URL will automatically change if the user uploads a new picture or removes it in the future. If you display profile pictures on your project website, this new endpoint eliminates the need for you to sync profile pictures as-well!

Important: Some of our services, such as GitLab, manage profile pictures independently and do not use this new endpoint. This change will not affect your picture on GitLab. To update your GitLab profile picture, visit your Eclipse GitLab Edit Profile page.

If you currently use Gravatar for your profile picture, it will no longer be displayed on sites like accounts.eclipse.org, projects.eclipse.org, blogs.eclipse.org, marketplace.eclipse.org, and newsroom.eclipse.org. To ensure your profile has a picture, please upload an Eclipse profile picture now in your account.

The post Date and Time Mappings with Hibernate and JPA appeared first on Thorben Janssen.

Databases support various data types to store date and time information. The most commonly used ones are: You can map all of them with JPA and Hibernate. But you need to decide to which Java type you want to map your database column. The Java language supports a bunch of classes to represent date and...

The post Date and Time Mappings with Hibernate and JPA appeared first on Thorben Janssen.

In this tutorial I want to consolidate some practical ideas regarding OpenTelemetry and how to use it with Spring Boot.

This tutorial is composed by four sections

1. OpenTelemetry practical concepts
2. Setting up an observability stack with OpenTelemetry Collector, Grafana, Loki, Tempo and Podman
3. Instrumenting Spring Boot applications for OpenTelemetry
4. Testing and E2E sample

By the end of the tutorial, you should be able to implement the following architecture:

OpenTelemetry practical concepts

As the official documentation states, OpenTelemetry is

• An Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs.
• Vendor and tool-agnostic, meaning that it can be used with a broad variety of Observability backends.
• Focused on the generation, collection, management, and export of telemetry. A major goal of OpenTelemetry is that you can easily instrument your applications or systems, no matter their language, infrastructure, or runtime environment.

Monitoring, observability and METL

To keep things short, monitoring is the process of collecting, processing and analyzing data to track the state of a (information) system. Then, monitoring is going to the next level, to actually understand the information that is being collected and do something with it, like defining alerts for a given system.

To achieve both goals it is necessary to collect three dimensions of data, specifically:

• Logs: Registries about processes and applications, with useful data like timestamps and context
• Metrics: Numerical data about the performance of applications and application modules
• Traces: Data that allow to estabilish the complete route that a given operation traverses through a series of dependent applications

Hence, when the state of a given system is altered in some way, we have an Event, that correlates and ideally generates data on the three dimensions.

Why is OpenTelemetry important and which problem does it solve?

Developers recognize by experience that monitoring and observability are important, either to evaluate the actual state of a system or to do post-mortem analysis after disasters. Hence, it is natural to think that observability has been implemented in various ways. For example if we think on a system constructed with Java we have at least the following collection points:

• Logs: Systemd, /var/log, /opt/tomcat, FluentD
• Metrics: Java metrics via JMX, OS Metrics, vendor specific metrics via Spring Actuator
• Tracing: Data via Jaeger or Zipkin tooling in our Java workloads

This variety in turn imposes a great amount of complexity in instrumenting our systems to provide information, that a- comes in different formats, from b- technology that is difficult to implement, often with c- solutions that are too tied to a given provider or in the worst cases, d- technologies that only work with certain languages/frameworks.

And that's the magic about OpenTelemetry proposal, by creating a working group under the CNCF umbrella the project is able to provide useful things like:

1. Common protocols that vendors and communities can implement to talk each other
2. Standards for software communities to implement instrumentation in libraries and frameworks to provide data in OpenTelemetry format
3. A collector able to retrieve/receive data from diverse origins compatible with OpenTelemetry, process it and send it to ...
4. Analysis platforms, databases and cloud vendors able to receive the data and provide added value over it

In short, OpenTelemetry is the reunion of various great monitoring ideas that overlapping software communities can implement to facilitate the burden of monitoring implementations.

OpenTelemetry data pipeline

For me, the easiest way to think about OpenTelemetry concepts is a data pipeline, in this data pipeline you need to

1. Instrument your workloads to push (or offer) the telemetry data to a processing/collecting element -i.e. OpenTelemetry Collector-
2. Configure OpenTelemetry Collector to receive or pull the data from diverse workloads
3. Configure OpenTelemetry Collector to process the data -i.e adding special tags, filtering data-
4. Configure OpenTelemetry Collector to push (or offer) the data to compatible backends
5. Configure and use the backends to receive (or pull) the data from the collector, to allow analysis, alarms, AI ... pretty much any case that you can think about with data

Setting up an observability stack with OpenTelemetry Collector, Grafana, Prometheus, Loki, Tempo and Podman

As OpenTelemetry got popular various vendors have implemented support for it, to mention a few:

Self-hosted platforms

• Elastic
• Grafana
• HyperDX

Cloud platforms

• Amazon
• Oracle Cloud
• Splunk
• Datadog

Hence, for development purposes, it is always useful to know how to bootstrap a quick observability stack able to receive and show OpenTelemetry capabilities.

For this purpose we will use the following elements:

• Prometheus as time-series database for metrics
• Loki as logs platform
• Tempo as a tracing platform
• Grafana as a web UI

And of course OpenTelemetry collector. This example is based on various Grafana examples, with a little bit of tweaking to demonstrate the different ways of collecting, processing and sending data to backends.

OpenTelemetry collector

As stated previously, OpenTelemetry collector acts as an intermediary that receives/pull information from data sources, processes this information and, forwards the information to destinations like analysis platforms or even other collectors. The collector is able to do this either with compliant workloads or via plugins that talk with the workloads using proprietary formats.

As the plugins collection can be increased or decreased, vendors have created their own distributions of OpenTelemetry collectors, for reference I've used successfully in the real world:

• Amazon ADOT
• Splunk Distribution of OpenTelemetry Collector
• Grafana Alloy
• OpenTelemetry Collector (the reference implementation)

You could find a complete list directly on OpenTelemetry website.

For this demonstration, we will create a data pipeline using the contrib version of the reference implementation which provides a good amount of receivers, exporters and processors. In our case Otel configuration is designed to:

• Receive data from Spring Boot workloads (ports 4317 and 4318)
• Process the data adding a new tag to metrics
• Expose an endpoint for Prometheus scrapping (port 8889)
• Send logs to Loki (port 3100) using otlphttp format
• Send traces to Tempo (port 9411) using otlp format
• Exposes a rudimentary dashboard from the collector, called zpages. Very useful for debugging.

otel-config.yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  attributes:
    actions:
      - key: team
        action: insert
        value: vorozco
exporters:
  debug:
  prometheus:
    endpoint: "0.0.0.0:8889"
  otlphttp:
    endpoint: http://loki:3100/otlp
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true
service:
  extensions: [zpages]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [attributes]
      exporters: [debug,prometheus]
    traces:
      receivers: [otlp]
      exporters: [debug, otlp]
    logs:
      receivers: [otlp]
      exporters: [debug, otlphttp]
extensions:
  zpages:
    endpoint: "0.0.0.0:55679"

Prometheus

Prometheus is a well known analysis platform, that among other things offers dimensional data and a performant time-series storage.

By default it works as a metrics scrapper, then, workloads provide a http endpoint offering data using the Prometheus format. For our example we configured Otel to offer metrics to the prometheus host via port 8889.

prometheus:
    endpoint: "prometheus:8889"

Then, whe need to configure Prometheus to scrape the metrics from the Otel host. You would notice two ports, the one that we defined for the active workload data (8889) and another for metrics data for the collector itself (8888).

prometheus.yml

scrape_configs:
- job_name: "otel"
  scrape_interval: 10s
  static_configs:
    - targets: ["otel:8889"]
    - targets: ["otel:8888"]

It is worth highlighting that Prometheus also offers a way to ingest information instead of scrapping it, and, the official support for OpenTelemetry ingestion is coming on the new versions.

Loki

As described in the website, Loki is a specific solution for log aggregation heavily inspired by Prometheus, with the particular design decision to NOT format in any way the log contents, leaving that responsibility to the query system.

To configure the project for local environments, the project offers a configuration that is usable for most of the development purposes. The following configuration is an adaptation to preserve the bare minimum to work with temporal files and memory.

loki.yaml

auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

common:
  instance_addr: 127.0.0.1
  path_prefix: /tmp/loki
  storage:
    filesystem:
      chunks_directory: /tmp/loki/chunks
      rules_directory: /tmp/loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

query_range:
  results_cache:
    cache:
      embedded_cache:
        enabled: true
        max_size_mb: 100

schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

ruler:
  alertmanager_url: http://localhost:9093

limits_config:
  allow_structured_metadata: true

Then, we configure an exporter to deliver the data to the loki host using oltphttp format.

otlphttp:
  endpoint: http://loki:3100/otlp

Tempo

In similar fashion than Loki, Tempo is an Open Source project created by grafana that aims to provide a distributed tracing backend. On a personal note, for me besides performance it shines for being compatible not only with OpenTelemetry, it can also ingest data in Zipkin and Jaeger formats.

To configure the project for local environments, the project offers a configuration that is usable for most of the development purposes. The following configuration is an adaptation to remove the metrics generation and simplify the configuration, however with this we loose the service graph feature.

tempo.yaml

stream_over_http_enabled: true
server:
  http_listen_port: 3200
  log_level: info

query_frontend:
  search:
    duration_slo: 5s
    throughput_bytes_slo: 1.073741824e+09
    metadata_slo:
      duration_slo: 5s
      throughput_bytes_slo: 1.073741824e+09
  trace_by_id:
    duration_slo: 5s

distributor:
  receivers:
    otlp:
      protocols:
        http:
        grpc:

ingester:
  max_block_duration: 5m               # cut the headblock when this much time passes. this is being set for demo purposes and should probably be left alone normally

compactor:
  compaction:
    block_retention: 1h                # overall Tempo trace retention. set for demo purposes

storage:
  trace:
    backend: local                     # backend configuration to use
    wal:
      path: /var/tempo/wal             # where to store the wal locally
    local:
      path: /var/tempo/blocks

Then, we configure an exporter to deliver the data to Tempo host using oltp/grpc format.

otlp:
    endpoint: tempo:4317
    tls:
      insecure: true

Grafana

Loki, Tempo and (to some extent) Prometheus are data storages, but we still need to show this data to the user. Here, Grafana enters the scene.

Grafana offers a good selection of analysis tools, plugins, dashboards, alarms, connectors and a great community that empowers observability. Besides having a great compatibility with Prometheus, it offers of course a perfect compatibility with their other offerings.

To configure Grafana you just need to plug compatible datasources and the rest of work will be on the web ui.

grafana.yaml

apiVersion: 1

datasources:
  - name: Otel-Grafana-Example
    type: prometheus
    url: http://prometheus:9090
    editable: true
  - name: Loki
    type: loki
    access: proxy
    orgId: 1
    url: http://loki:3100
    basicAuth: false
    isDefault: true
    version: 1
    editable: false
  - name: Tempo
    type: tempo
    access: proxy
    orgId: 1
    url: http://tempo:3200
    basicAuth: false
    version: 1
    editable: false
    apiVersion: 1
    uid: tempo

Podman (or Docker)

At this point you may have noticed that I've referred to the backends using single names, this is because I intend to set these names using a Podman Compose deployment.

otel-compose.yml

version: '3'
services:
  otel:
    container_name: otel
    image: otel/opentelemetry-collector-contrib:latest
    command: [--config=/etc/otel-config.yml]
    volumes:
      - ./otel-config.yml:/etc/otel-config.yml
    ports:
      - "4318:4318"
      - "4317:4317"
      - "55679:55679"
  prometheus:
    container_name: prometheus
    image: prom/prometheus
    command: [--config.file=/etc/prometheus/prometheus.yml]
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9091:9090"
  grafana:
    container_name: grafana
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    image: grafana/grafana
    volumes:
      - ./grafana.yml:/etc/grafana/provisioning/datasources/default.yml
    ports:
      - "3000:3000"
  loki:
    container_name: loki
    image: grafana/loki:3.2.0
    command: -config.file=/etc/loki/local-config.yaml
    volumes:
      - ./loki.yaml:/etc/loki/local-config.yaml
    ports:
      - "3100"
  tempo:
    container_name: tempo
    image: grafana/tempo:latest
    command: [ "-config.file=/etc/tempo.yaml" ]
    volumes:
      - ./tempo.yaml:/etc/tempo.yaml
    ports:
      - "4317"  # otlp grpc
      - "4318"

At this point the compose description is pretty self-descriptive, but I would like to highlight some things:

• Some ports are open to the host -e.g. 4318:4318 - while others are closed to the default network that compose will be created among containers -e.g. 3100-
• This stack is designed to avoid any permanent data. Again, this is my personal way to boot quickly an observability stack to allow tests during deployment. To make it ready for production you probably would want to preserve the data in some volumes

Once the configuration is ready, you can launch it using the compose file

cd podman
podman compose -f otel-compose.yml up

If the configuration is ok, you should have five containers running without errors.

Instrumenting Spring Boot applications for OpenTelemetry

As part of my daily activities I was in charge of a major implementation of all these concepts. Hence it was natural for me to create a proof of concept that you could find at my GitHub.

For demonstration purposes we have two services with different HTTP endpoints:

• springboot-demo:8080 - Useful to demonstrate local and database tracing, performance, logs and OpenTelemetry instrumentation
  • /books - A books CRUD using Spring Data
  • /fibo - A Naive Fibonacci implementation that generates CPU load and delays
  • /log - Which generate log messages using the different SLF4J levels
• springboot-client-demo:8081 - Useful to demonstrate tracing capabilities, Micrometer instrumentation and Micrometer Tracing instrumentation
  • /trace-demo - A quick OpenFeing client that invokes books GetAll Books demo

Instrumentation options

Given the popularity of OpenTelemetry, developers can expect also multiple instrumentation options.

First of all, the OpenTelemetry project offers a framework-agnostic instrumentation that uses bytecode manipulation, for this instrumentation to work you need to include a Java Agent via Java Classpath. In my experience this instrumentation is preferred if you don't control the workload or if your platform does not offer OpenTelemetry support at all.

However, instrumentation of workloads can become really specific -e.g. instrumentation of a Database pool given a particular IoC mechanism-. For this, the Java world provides a good ecosystem, for example:

• Quarkus
• Helidon
• Payara

And of course Spring Boot.

Spring Boot is a special case with TWO major instrumentation options

1. OpenTelemetry's Spring Boot starter
2. Micrometer and Micrometer Tracing

Both options use Spring concepts like decorators and interceptors to capture and send information to the destinations. The only rule is to create the clients/services/objects in the Spring way (hence via Spring IoC).

I've used both successfully and my heavily opinionated conclusion is the following:

• Micrometer collects more information about spring metrics. Besides OpenTelemetry backend, it supports a plethora of backends directly without any collector intervention. If you cannot afford a collector, this is the way. From Micrometer perspective OpenTelemetry is just another backend
• Micrometer Tracing is the evolution of Spring Cloud Sleuth, hence if you have workloads with Spring Boot 2 and 3, you have to support both tools (or maybe migrate everything to Spring boot 3?)
• The Micrometer family does not offer a way to collect logs and send these to a backend, hence devs have to solve this by using an appender specific to your logging library. On the other hand OpenTelemetry Spring Boot starter offers this out of the box if you use Spring Boot default (SLF4J over Logback)

As these libraries are mutually exclusive, if the decision is mine, I would pick OpenTelemetry's Spring Boot starter. It offers logs support OOB and also a bridge for micrometer Metrics.

Instrumenting springboot-demo with OpenTelemetry SpringBoot starter

As always, it is also good to consider the official documentation.

Otel instrumentation with the Spring started is activated in three steps:

1. You need to include both OpenTelemetry Bom and OpenTelemetry dependency. If you are planning to also use micrometer metrics, it is also a good idea to include Spring Actuator

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.opentelemetry.instrumentation</groupId>
            <artifactId>opentelemetry-instrumentation-bom</artifactId>
            <version>2.10.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
...
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency>

1. There is a set of optional libraries and adapters that you can configure if your workloads already diverged from the "Spring Way"

2. You need to activate (or not) the dimensions of observability (metrics, traces and logs). Also, you can finetune the exporting parameter like ports, urls or exporting periods. Either by using Spring Properties or env variables

#Configure exporters
otel.logs.exporter=otlp
otel.metrics.exporter=otlp
otel.traces.exporter=otlp

#Configure metrics generation
otel.metric.export.interval=5000 #Export metrics each five seconds
otel.instrumentation.micrometer.enabled=true #Enabe Micrometer metrics bridge

Instrumenting springboot-client-demo with Micrometer and Micrometer Tracing

Again, this instrumentation does not support logs exporting. Also, it is a good idea to check the latest documentation for Micrometer and Micrometer Tracing.

1. As in the previous example, you need to enable Spring Actuator (which includes Micrometer). As OpenTelemetry is just a backend from Micrometer perspective, you just need to ehable the corresponding OTLP registry which will export metrics to localhost by default.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-otlp</artifactId>
</dependency>

1. In a similar way you need to Metrics, once actuator is enabled you just need to add support for the tracing backend

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>

1. Finally, you can finetune the configuration using Spring properties. For example, you can decide if 100% of traces are reproted or how often the metrics are reported to the backend.

management.otlp.tracing.endpoint=http://localhost:4318/v1/traces
management.otlp.tracing.timeout=10s
management.tracing.sampling.probability=1

management.otlp.metrics.export.url=http://localhost:4318/v1/metrics
management.otlp.metrics.export.step=5s
management.opentelemetry.resource-attributes."service-name"=${spring.application.name}

Testing and E2E sample

Generating workload data

The POC provides the following structure

├── podman # Podman compose config files
├── springboot-client-demo #Spring Boot Client instrumented with Actuator, Micrometer and MicroMeter tracing 
└── springboot-demo #Spring Boot service instrumented with OpenTelemetry Spring Boot Starter

1. The first step is to boot the observability stack we created previously.

cd podman
podman compose -f otel-compose.yml up

This will provide you an instance of Grafana on port 3000

Then, it is time to boot the first service!. You only need Java 21 on the active shell:

cd springboot-demo
mvn spring-boot:run

If the workload is properly configured, you will see the following information on the OpenTelemetry container standard output. Which basically says you are successfully reporting data.

[otel]       | 2024-12-01T22:10:07.730Z info    Logs    {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 24}
[otel]       | 2024-12-01T22:10:10.671Z info    Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 64, "data points": 90}
[otel]       | 2024-12-01T22:10:10.672Z info    Traces  {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 1, "spans": 5}
[otel]       | 2024-12-01T22:10:15.691Z info    Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 65, "data points": 93}
[otel]       | 2024-12-01T22:10:15.833Z info    Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 65, "data points": 93}
[otel]       | 2024-12-01T22:10:15.835Z info    Logs    {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 5}

The data is being reported over the OpenTelemetry ports (4317 and 4318) which are open from Podman to the host. By default all telemetry libraries report to localhost, but this can be configured for other cases like FaaS or Kubernetes.

Also, you could verify the reporting status in ZPages

Finally let's do the same with Spring Boot client:

cd springboot-client-demo
mvn spring-boot:run

As described in the previous section, I created a set of interactions to:

Generate CPU workload using Naive fibonacci

curl http://localhost:8080/fibo\?n\=45

Generate logs in different levels

curl http://localhost:8080/fibo\?n\=45

Persist data using a CRUD

curl -X POST --location "http://localhost:8080/books" \
-H "Content-Type: application/json" \
-d '{
"author": "Miguel Angel Asturias",
"title": "El señor presidente",
"isbn": "978-84-376-0494-7",
"publisher": "Editorial planeta"
}'

And then retrieve the data using a secondary service

curl http://localhost:8081/trace-demo 

This asciicast shows the interaction:

Grafana results

Once the data is accesible by Grafana, the what to do with data is up to you, again, you could:

• Create dashboards
• Configure alarms
• Configure notifications from alarms

The quickest way to verify if the data is reported correctly is to verify directly in Grafana explore.

First, we can check some metrics like system_cpu_usage and filter by service name. In this case I used springboot-demo which has the CPU demo using naive fibonacci, I can even filter by my own tag (which was added by Otel processor):

In the same way, logs are already stored in Loki:

Finally, we could check the whole trace, including both services and interaction with H2 RDBMS:

This tutorial provides an overview of some of the new features that are available in the upcoming Jakarta Persistence API 3.2, which is part of Jakarta EE 11 bundle. Jakarta Persistence defines a standard for management of persistence and ORM Java(R) Enterprise environments. If you are new to Jakarta Persistence API we recommend checking this ... Read more

The post What is new in Jakarta Persistence 3.2 appeared first on Mastertheboss.

Introduction

Concurrency has always been a cornerstone of Java, but as applications scale and demands for high throughput and low latency increase, traditional threading models show their limitations. Project Loom and its groundbreaking introduction of virtual threads redefines how we approach concurrency in Java, making applications more scalable and development more straightforward.

In this post, we’ll go deep into virtual threads, exploring how they work, their impact on scalability, and how they simplify backend development. We’ll provide both simple and complex code examples to illustrate these concepts in practice.

The Limitations of Traditional Threads

In Java, each thread maps to an operating system (OS) thread. While this model is straightforward, it comes with significant overhead:

• Resource Consumption: OS threads are heavy-weight, consuming considerable memory (~1MB stack size by default).
• Context Switching: The OS has to manage context switching between threads, which can degrade performance when thousands of threads are involved.
• Scalability Issues: Blocking operations (e.g., I/O calls) tie up OS threads, limiting scalability.

Traditional solutions involve complex asynchronous programming models or reactive frameworks, which can make code harder to read and maintain.

Introducing Virtual Threads

Virtual threads are “lightweight” threads that aim to solve these problems:

• Lightweight: Thousands of virtual threads can be created without significant overhead.
• Efficient Scheduling: Managed by the JVM rather than the OS, leading to more efficient context switching.
• Simplified Concurrency: Enable writing straightforward, blocking code without sacrificing scalability.

Virtual threads decouple the application thread from the OS thread, allowing the JVM to manage threading more efficiently.

How Virtual Threads Work

Under the hood, virtual threads are scheduled by the JVM onto a pool of OS threads. Key aspects include:

• Continuation-Based: Virtual threads use continuations to save and restore execution state.
• Non-Blocking Operations: When a virtual thread performs a blocking operation, it yields control, allowing the JVM to schedule another virtual thread.
• Efficient Utilization: The JVM reuses OS threads, minimizing the cost of context switches.

Here’s a simplified diagram:

[plant uml diagram]

Benefits of Virtual Threads

• Scalability: Handle millions of concurrent tasks with minimal resources.
• Simplified Code: Write blocking code without complex asynchronous patterns.
• Performance: Reduced context switching overhead and better CPU utilization.
• Integration: Works seamlessly with existing Java code and libraries.

Simple Examples

Example 1: Spawning Virtual Threads

public class VirtualThreadExample {
    public static void main(String[] args) throws InterruptedException {
        Thread.startVirtualThread(() -> {
            System.out.println("Hello from a virtual thread!");
        });

        // Alternatively, using Thread.Builder
        Thread thread = Thread.builder()
                .virtual()
                .task(() -> System.out.println("Another virtual thread"))
                .start();

        thread.join();
    }
}

Explanation:

• Thread.startVirtualThread creates and starts a virtual thread.
• Virtual threads behave like regular threads but are lightweight.

Example 2: Migrating from Traditional to Virtual Threads

Traditional threading:

ExecutorService executor = Executors.newFixedThreadPool(10);

for (int i = 0; i < 100; i++) {
    executor.submit(() -> {
        // Perform task
    });
}

executor.shutdown();

Using virtual threads:

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

for (int i = 0; i < 100; i++) {
    executor.submit(() -> {
        // Perform task
    });
}

executor.shutdown();

Explanation:

• Executors.newVirtualThreadPerTaskExecutor() creates an executor that uses virtual threads.
• We can submit a large number of tasks without worrying about thread exhaustion.

Complex Examples

Example 1: High-Throughput Server with Virtual Threads

Let’s build a server that handles a massive number of connections using virtual threads.

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class VirtualThreadServer {
    public static void main(String[] args) throws IOException {
        try (ServerSocket serverSocket = new ServerSocket(8080)) {
            while (true) {
                Socket clientSocket = serverSocket.accept();

                Thread.startVirtualThread(() -> handleClient(clientSocket));
            }
        }
    }

    private static void handleClient(Socket clientSocket) {
        try (clientSocket) {
            // Read from and write to the client
            clientSocket.getOutputStream().write("HTTP/1.1 200 OK\r\n\r\nHello World".getBytes());
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Explanation:

• Each incoming connection is handled by a virtual thread.
• The server can handle a vast number of simultaneous connections efficiently.

Performance Considerations:

• Blocking I/O operations in virtual threads do not block OS threads.
• The JVM efficiently manages the scheduling of virtual threads.

Example 2: Custom Virtual Thread Executor Service

Creating a custom executor service that manages virtual threads with specific configurations.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadFactory;

public class CustomVirtualThreadExecutor {
    public static void main(String[] args) {
        ThreadFactory factory = Thread.builder()
                .virtual()
                .name("virtual-thread-", 0)
                .factory();

        ExecutorService executor = Executors.newThreadPerTaskExecutor(factory);

        for (int i = 0; i < 1000; i++) {
            int taskNumber = i;
            executor.submit(() -> {
                System.out.println(Thread.currentThread().getName() + " executing task " + taskNumber);
                // Simulate work
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        executor.shutdown();
    }
}

Explanation:

• Using Thread.builder(), we create a custom thread factory for virtual threads with a naming pattern.
• The executor service uses this factory to create virtual threads per task.
• This setup allows for customized thread creation and better debugging.

Example 3: Structured Concurrency with Virtual Threads

Structured concurrency helps manage multiple concurrent tasks as a single unit.

import java.time.Duration;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.StructuredTaskScope;

public class StructuredConcurrencyExample {
    public static void main(String[] args) {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            var future1 = scope.fork(() -> fetchDataFromServiceA());
            var future2 = scope.fork(() -> fetchDataFromServiceB());

            scope.join();           // Wait for all tasks
            scope.throwIfFailed();  // Propagate exceptions

            String resultA = future1.resultNow();
            String resultB = future2.resultNow();

            System.out.println("Results: " + resultA + ", " + resultB);
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        }
    }

    private static String fetchDataFromServiceA() throws InterruptedException {
        Thread.sleep(Duration.ofSeconds(2));
        return "Data from Service A";
    }

    private static String fetchDataFromServiceB() throws InterruptedException {
        Thread.sleep(Duration.ofSeconds(3));
        return "Data from Service B";
    }
}

Explanation:

• StructuredTaskScope allows grouping tasks and managing them collectively.
• ShutdownOnFailure ensures that if one task fails, all others are canceled.
• Virtual threads make this pattern efficient and practical.

Benefits:

• Simplifies error handling in concurrent code.
• Improves readability and maintainability.

Impact on Backend Development

Virtual threads have profound implications for backend development:

Simplified Codebases

In traditional Java, we often use non-blocking I/O to achieve concurrency, which can complicate code structure. With virtual threads, we can use blocking code without the performance penalties associated with OS threads.

Example Without Virtual Threads (Using Asynchronous I/O):

CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    try {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder(URI.create("https://example.com")).build();
        client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
              .thenAccept(response -> System.out.println(response.body()));
    } catch (Exception e) {
        e.printStackTrace();
    }
});

Simplified with Virtual Threads:

Thread.startVirtualThread(() -> {
    try {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder(URI.create("https://example.com")).build();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        System.out.println(response.body());
    } catch (Exception e) {
        e.printStackTrace();
    }
});

With virtual threads, we can use synchronous client.send() directly, making the code simpler and more readable, while still benefiting from concurrency.

Elimination of Callback Hell

Asynchronous programming often leads to nested callbacks, which make the code harder to read and debug. Virtual threads allow us to write code in a linear, blocking style, avoiding callback hell.

Example Using Callbacks (Without Virtual Threads):

fetchDataAsync("https://example.com/data", result -> {
    processAsync(result, processed -> {
        saveAsync(processed, saved -> {
            System.out.println("Data saved successfully!");
        });
    });
});

Simplified with Virtual Threads:

Thread.startVirtualThread(() -> {
    String data = fetchData("https://example.com/data");
    String processed = process(data);
    save(processed);
    System.out.println("Data saved successfully!");
});

With virtual threads, we can write sequential, synchronous code while retaining concurrency, eliminating the need for nested callbacks.

Enhanced Performance

Handling many concurrent requests with traditional threads can quickly lead to memory exhaustion. Virtual threads allow us to handle a large number of connections concurrently with minimal resource overhead.

Example: High-Concurrency Server with Virtual Threads

try (var serverSocket = new ServerSocket(8080)) {
    while (true) {
        var clientSocket = serverSocket.accept();
        Thread.startVirtualThread(() -> handleClient(clientSocket));
    }
}

private static void handleClient(Socket clientSocket) {
    try (clientSocket) {
        clientSocket.getOutputStream().write("HTTP/1.1 200 OK\r\n\r\nHello, World!".getBytes());
    } catch (IOException e) {
        e.printStackTrace();
    }
}

This server can handle thousands of simultaneous connections without exhausting system resources, as each connection runs on a virtual thread.

Compatibility with Existing Libraries and Frameworks

Since virtual threads are part of the standard Java threading API, they are compatible with most existing libraries and frameworks, allowing developers to integrate virtual threads without extensive refactoring.

Example: Using Virtual Threads with ExecutorService

You can replace traditional thread pools with virtual thread-based executors to use existing code with minimal changes.

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

for (int i = 0; i < 100; i++) {
    executor.submit(() -> {
        System.out.println("Running task on a virtual thread.");
    });
}

executor.shutdown();

Any code that works with ExecutorService will continue to work seamlessly with virtual threads, enhancing compatibility.

Reduced Need for Reactive Frameworks

Virtual threads allow developers to use blocking code patterns without the overhead associated with OS threads, making it possible to achieve high concurrency with simpler code structures, reducing the need for reactive frameworks.

Example: Synchronous Data Fetching with Virtual Threads Instead of Reactive Patterns

Reactive (Without Virtual Threads):

Mono<String> data = WebClient.create("https://example.com")
    .get()
    .retrieve()
    .bodyToMono(String.class);

data.subscribe(System.out::println);

Simplified with Virtual Threads:

Thread.startVirtualThread(() -> {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest request = HttpRequest.newBuilder(URI.create("https://example.com")).build();
    String response = client.send(request, HttpResponse.BodyHandlers.ofString()).body();
    System.out.println(response);
});

Virtual threads allow us to use blocking code directly, making reactive patterns unnecessary for some use cases. This reduces complexity, especially for applications that don’t require the full power of reactive programming.

Considerations

When implementing virtual threads with Project Loom, developers must consider various technical and architectural implications. Below are some detailed considerations to keep in mind:

Memory Usage and Stack Management

Virtual threads are lightweight compared to traditional OS threads, but they still consume memory, especially if the virtual threads are highly stacked (deep call stacks).

• Stack Size: Virtual threads start with a small stack and can expand as needed, which can potentially reduce memory consumption compared to OS threads. However, developers should monitor stack usage to avoid excessive memory consumption.
• Memory Monitoring: Although virtual threads are efficient, monitoring the JVM’s memory usage becomes essential as thousands of virtual threads may be active concurrently.
• JVM Configuration: Tuning the JVM’s garbage collection and memory settings is important when handling millions of threads, as they may put unexpected pressure on the heap.

Blocking vs. Non-Blocking Code Patterns

Virtual threads make blocking I/O efficient, but there are some nuances:

• Blocking I/O Operations: With virtual threads, you can use blocking calls like Socket or File I/O without performance penalties. However, the JVM handles only traditional blocking I/O efficiently, so libraries must be updated for Loom support.
• Non-Blocking I/O: If your project is already using non-blocking I/O, switching to virtual threads might simplify the code structure but won’t necessarily bring significant performance gains, as non-blocking code is already optimized.
• Thread Pool Alternatives: In traditional models, a common technique is to use a pool of threads to limit the number of concurrent operations. With virtual threads, this might no longer be necessary, allowing a model where each task gets its own virtual thread without causing bottlenecks.

Concurrency Limitations

While virtual threads allow for a high degree of concurrency, they are not a silver bullet. Certain scenarios, such as CPU-bound tasks, still require careful handling to avoid performance degradation.

• CPU-Bound Tasks: Virtual threads are designed for I/O-bound workloads. If the application has CPU-intensive tasks, virtual threads might not yield the same benefits, as they do not reduce CPU time requirements.
• Parallelism Control: For tasks that require controlled parallelism, developers may still benefit from combining virtual threads with task-limiting mechanisms (e.g., limiting the number of CPU-bound threads).
• Thread Priority and Scheduling: Virtual threads are managed by the JVM and may not respect OS-level thread priorities. If your application requires fine-grained control over thread priority, virtual threads might not be ideal.

Error Handling and Exception Propagation

Error handling becomes crucial, especially with the simplicity of launching thousands of threads.

• Propagating Exceptions: Virtual threads handle exceptions differently; uncaught exceptions in a virtual thread do not terminate the JVM process but are logged or can be handled asynchronously.
• Graceful Shutdowns: Virtual threads simplify concurrency, but managing error states across thousands of threads can be challenging. Structured concurrency (a model for grouping and managing threads introduced alongside Loom) helps manage error propagation and task cancellation.
• Task Scopes: When using structured concurrency with virtual threads, grouping tasks with scopes (e.g., ShutdownOnFailure in Java’s StructuredTaskScope) ensures that if one task in a group fails, other tasks can be canceled or handled appropriately.

Impact on Debugging and Profiling

With potentially millions of threads, debugging and profiling virtual-threaded applications introduce unique challenges.

• Thread Explosion in Debuggers: Debuggers might struggle with applications using millions of virtual threads, leading to overwhelming output. It may be helpful to add application-level logging or selectively enable virtual threads for debugging.
• Profiling Complexity: Traditional thread profilers may not provide granular insights for virtual threads. Consider using JVM flight recording or Loom-aware profiling tools to trace virtual thread usage accurately.
• Stack Trace Analysis: Virtual threads make it possible to have more granular and descriptive stack traces, but interpreting large volumes of stack traces could require additional tooling or filtering strategies.

Interplay with Synchronization and Locks

Though virtual threads alleviate many concurrency issues, developers still need to be cautious with shared resources.

• Contention on Shared Resources: Virtual threads do not inherently solve issues related to contention on shared resources. If two virtual threads try to acquire the same lock, they may still face contention, potentially leading to bottlenecks.
• Thread Safety: Existing synchronized code will generally work with virtual threads. However, in a highly concurrent environment, developers should consider using java.util.concurrent locks (e.g., ReentrantLock with try-lock mechanisms) or lock-free data structures to avoid contention.
• Deadlock Risks: While virtual threads reduce many resource-related problems, deadlocks can still occur if resources are mismanaged. Deadlock analysis tools can help in identifying potential deadlock situations.

Structured Concurrency for Task Management

Structured concurrency in Project Loom allows developers to group threads and manage them collectively, making error handling and task cancellation more intuitive.

• Parent-Child Relationships: Structured concurrency introduces a parent-child relationship between tasks, simplifying lifecycle management and error propagation.
• Graceful Cancellation: If a parent task is canceled, all child tasks are automatically canceled, making it easier to handle scenarios where one task failure requires the cancellation of other related tasks.
• Scope Lifecycle Management: With StructuredTaskScope, developers can define a task group’s lifecycle. This ensures that resources are managed properly, and all tasks in the scope are completed, failed, or canceled together.

Interfacing with Existing Thread-Based Libraries

Virtual threads integrate well with many libraries but may require attention with those heavily reliant on OS-level threads or specialized thread management.

• OS-Threaded Libraries: Libraries that rely on low-level OS-thread management (e.g., JNI-based libraries) may not benefit directly from virtual threads, as they may require actual OS threads for certain operations.
• External Thread Pools: If your application integrates with external thread pools (e.g., database connection pools), consider switching to Loom-compatible connection handling, as some third-party libraries may not yet support virtual threads.
• Task Executors: Replacing ThreadPoolExecutor with Executors.newVirtualThreadPerTaskExecutor() allows easier adaptation to existing thread-based code, but testing is recommended to ensure compatibility and performance stability.

Performance Profiling and Resource Management

Virtual threads reduce context-switching overhead and make high-concurrency applications more feasible, but monitoring and optimizing performance remain crucial.

• Avoiding Thread Overuse: Although virtual threads are lightweight, overusing them (e.g., starting a new thread for every small task) can still degrade performance. Consider batching or grouping tasks when feasible.
• Heap Pressure and Garbage Collection: Large numbers of virtual threads may generate considerable garbage, adding pressure on the JVM’s garbage collection. Profiling and tuning the GC for high-throughput applications with virtual threads is crucial.
• Application Profiling: Java Flight Recorder (JFR) or other profiling tools with virtual-thread awareness can help understand the application’s runtime characteristics, especially in production environments.

Testing and Migration Strategies

Testing and planning migration from traditional to virtual threads require thorough analysis and validation.

• Gradual Migration: Virtual threads allow a gradual migration. Developers can begin by converting specific thread-heavy sections of the application to virtual threads while retaining traditional threads elsewhere.
• Testing for Loom Compatibility: While most Java libraries are expected to be compatible, rigorous testing is recommended, particularly for libraries with complex threading requirements or blocking operations.
• Load Testing and Performance Validation: Applications utilizing virtual threads should undergo load testing to validate that the new threading model provides the expected concurrency improvements without introducing regressions or bottlenecks.

Patterns and Anti-Patterns

After all beeing said lets examine some common patterns and antipatterns

Patterns

Task-Per-Thread Pattern

One of the primary use cases for virtual threads is to simplify concurrency by using a “task-per-thread” model. In this pattern, each concurrent task is assigned to a separate virtual thread, which avoids the complex management typically needed for thread pools with OS threads.

Example: A server handling multiple incoming connections, with each connection running in its own virtual thread.

try (ServerSocket serverSocket = new ServerSocket(8080)) {
    while (true) {
        Socket clientSocket = serverSocket.accept();
        Thread.startVirtualThread(() -> handleClient(clientSocket));
    }
}

private static void handleClient(Socket clientSocket) {
    try (clientSocket) {
        clientSocket.getOutputStream().write("HTTP/1.1 200 OK\r\n\r\nHello, World!".getBytes());
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Each connection is handled by a virtual thread, providing simple and scalable concurrency without the need for a complex thread pool. This pattern would be inefficient with OS threads but is efficient with virtual threads.

Structured Concurrency Pattern

Structured concurrency organizes concurrent tasks as a structured unit, making it easier to manage lifecycles, cancellations, and exceptions. This pattern is particularly useful in request-based applications where tasks are interdependent.

Example: Fetching data from multiple services concurrently and consolidating the results.

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var future1 = scope.fork(() -> fetchDataFromServiceA());
    var future2 = scope.fork(() -> fetchDataFromServiceB());

    scope.join();           // Wait for all tasks to complete
    scope.throwIfFailed();  // Handle exceptions

    String resultA = future1.resultNow();
    String resultB = future2.resultNow();
    System.out.println("Results: " + resultA + ", " + resultB);
} catch (Exception e) {
    e.printStackTrace();
}

Structured concurrency ensures that if any task fails, all other tasks in the same scope are canceled. It simplifies error handling and improves resource management, providing better control over concurrent flows.

Blocking Code in Virtual Threads

With virtual threads, developers can safely use blocking calls, such as Thread.sleep() or blocking I/O operations, as the JVM handles scheduling efficiently. This pattern contrasts with the traditional approach of avoiding blocking calls to prevent thread starvation.

Example: Running blocking I/O operations without impacting overall performance.

Thread.startVirtualThread(() -> {
    try {
        Thread.sleep(1000);  // Blocking call
        System.out.println("Virtual thread finished sleeping");
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

Virtual threads make blocking operations efficient, as the JVM schedules other virtual threads to run while the blocking call is in progress. This allows developers to write simpler, more readable code without performance trade-offs.

Task-Based Executors with Virtual Threads

Using Executors.newVirtualThreadPerTaskExecutor() creates a virtual-thread-based executor that simplifies parallel task execution. This pattern allows developers to leverage the ExecutorService interface, making it easy to transition from traditional threads to virtual threads.

Example: Running multiple tasks concurrently with a virtual-thread-based executor.

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

for (int i = 0; i < 10; i++) {
    executor.submit(() -> {
        System.out.println("Running task on virtual thread: " + Thread.currentThread().getName());
    });
}

executor.shutdown();

This executor allows each task to run on a virtual thread, making it efficient to create a new thread per task without the need for traditional thread pooling.

Anti-Patterns

Overuse of Virtual Threads

While virtual threads are lightweight, they are not “free.” Creating excessive numbers of virtual threads for very short-lived tasks can introduce overhead in terms of scheduling and garbage collection, which may impact performance.

Anti-Pattern Example: Creating a new virtual thread for every small task, such as iterating over a list.

List<String> items = List.of("A", "B", "C");
for (String item : items) {
    Thread.startVirtualThread(() -> processItem(item));  // Inefficient
}

Better Approach: Instead, batch tasks together if they are very short-lived to avoid excessive thread creation.

Thread.startVirtualThread(() -> items.forEach(VirtualThreadsExample::processItem));

By batching the tasks within a single virtual thread, you avoid creating unnecessary threads, optimizing resource usage and reducing scheduling overhead.

Blocking OS Resources in Virtual Threads

Blocking calls that involve resources controlled by the OS, such as file locks or certain low-level network operations, may still tie up OS threads when used with virtual threads, leading to potential bottlenecks.

Anti-Pattern Example: Locking a file for extended periods in a virtual thread.

Thread.startVirtualThread(() -> {
    try (var fileChannel = FileChannel.open(Path.of("file.txt"), StandardOpenOption.WRITE)) {
        fileChannel.lock();  // This can block an OS thread, not recommended
    } catch (IOException e) {
        e.printStackTrace();
    }
});

Better Approach: Avoid blocking virtual threads on OS resources that do not release quickly. Use asynchronous approaches for tasks involving external resources.

Improper Exception Handling in Virtual Threads

Exceptions in virtual threads do not terminate the JVM, and uncaught exceptions in virtual threads may not be logged as prominently as in traditional threads, leading to undetected errors.

Anti-Pattern Example: Ignoring exceptions in virtual threads.

Thread.startVirtualThread(() -> {
    int result = 10 / 0;  // Unhandled exception
    System.out.println("Result: " + result);
});

Better Approach: Use structured concurrency or set up explicit exception handling within virtual threads to capture and handle errors effectively.

Thread.startVirtualThread(() -> {
    try {
        int result = 10 / 0;
        System.out.println("Result: " + result);
    } catch (Exception e) {
        System.err.println("Error in virtual thread: " + e.getMessage());
    }
});

Proper error handling in virtual threads helps in identifying and managing issues without causing untracked failures.

Manual Management of Thread Lifecycles

With virtual threads, the need for manually managing thread lifecycles or using traditional thread pooling mechanisms decreases. Creating a custom virtual-thread pool or managing virtual threads directly as a group is often unnecessary and counterproductive.

Anti-Pattern Example: Manually creating a virtual-thread pool.

List<Thread> virtualThreadPool = new ArrayList<>();
for (int i = 0; i < 10; i++) {
    virtualThreadPool.add(Thread.startVirtualThread(() -> System.out.println("Task in virtual pool")));
}
virtualThreadPool.forEach(t -> {
    try {
        t.join();
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

Better Approach: Use Executors.newVirtualThreadPerTaskExecutor() to manage tasks rather than manually handling virtual threads.

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

for (int i = 0; i < 10; i++) {
    executor.submit(() -> System.out.println("Task in virtual thread executor"));
}

executor.shutdown();

Manually creating and managing virtual-thread pools contradicts the efficiency of built-in virtual-thread executors, which are optimized for this purpose.

Over-Reliance on Virtual Threads for CPU-Bound Tasks

Virtual threads excel in I/O-bound tasks, but for CPU-bound tasks, they offer limited benefits. Virtual threads do not reduce the CPU time required, so heavy reliance on virtual threads for CPU-bound operations can lead to high contention and degraded performance.

Anti-Pattern Example: Running a CPU-intensive task on a high number of virtual threads.

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
for (int i = 0; i < 100; i++) {
    executor.submit(() -> performCPUIntensiveTask());
}

Better Approach: Use a fixed-size thread pool for CPU-bound tasks to limit the number of concurrent CPU-intensive operations.

ExecutorService cpuExecutor = Executors.newFixedThreadPool(4);  // Adjust pool size for CPU cores
for (int i = 0; i < 100; i++) {
    cpuExecutor.submit(() -> performCPUIntensiveTask());
}
cpuExecutor.shutdown();

Using a fixed-size pool for CPU-bound tasks helps manage CPU usage and avoids overwhelming the CPU with excessive task scheduling.

Relying on Global State in Virtual Threads

Virtual threads can be short-lived and numerous, so relying on shared global state can lead to contention and potential race conditions, especially when many virtual threads attempt to access or modify the state concurrently.

Anti-Pattern Example: Modifying shared global state from multiple virtual threads.

public static int counter = 0;

for (int i = 0; i < 1000; i++) {
    Thread.startVirtualThread(() -> counter++);
}

Better Approach: Use thread-safe data structures or local variables to reduce contention. For counters, consider using AtomicInteger or other concurrent collections.

AtomicInteger counter = new AtomicInteger();

for (int i = 0; i < 1000; i++) {
    Thread.startVirtualThread(() -> counter.incrementAndGet());
}

Avoiding shared global state or using thread-safe structures reduces contention and prevents data corruption, especially in high-concurrency environments.

Conclusion

Project Loom’s virtual threads bring a groundbreaking shift to Java’s concurrency model, allowing developers to write more intuitive, efficient, and scalable concurrent code. By making virtual threads lightweight and capable of handling blocking operations without tying up OS resources, Project Loom simplifies complex concurrency patterns, allowing developers to write straightforward, blocking code that performs well under high concurrency.

Key patterns, such as task-per-thread, structured concurrency, and asynchronous handling of OS-bound tasks, demonstrate how virtual threads can enhance both code simplicity and application performance. These patterns, combined with new APIs, like StructuredTaskScope, make it easier to handle interdependent tasks, manage cancellations, and propagate exceptions in a cohesive way. At the same time, understanding anti-patterns—such as avoiding excessive thread creation for short-lived tasks or blocking on OS-level resources—is essential to prevent bottlenecks and ensure efficient resource usage.

Virtual threads encourage developers to rethink their approach to concurrency, moving away from complex reactive frameworks or callback-heavy asynchronous code toward a more synchronous and readable model. However, for CPU-bound tasks or specific I/O operations that require OS thread involvement, traditional approaches like fixed-thread pools and asynchronous task delegation remain relevant.

In essence, virtual threads make concurrency accessible and manageable, even for complex applications, while allowing developers to focus on the core logic rather than threading intricacies. As virtual threads become standard, Java developers can embrace a more flexible and high-performing concurrency model that scales efficiently and integrates smoothly with existing libraries and frameworks, setting the stage for a new era in Java application development.

Hi guys, how’s it going? Long time no see!

In fact, I had been very silent in the past months, and as you could imagine, it has a reason: I just had no time to share all the great stuff with you that I was involved with recently. In particular, creating video content for Youtube is such time-consuming that I decided to stop with that by end of 2023, at least “for some time”, until my personal stress level is “normalized” again. Unfortunately, now by end of 2024, it still is at 250%… Anyways!

Having said that, I decided to restart my blog. While many people told me that blogging is @depreceated since the invention of VLogs, I need to say, it is just so much easier for me to write a blog article, that I decided to ignore them and write some lines about my latest Open Source contribution. So here it is: My first blog entry in years!

But enough about me. What I actually wanted to tell you today is that I am totally happy these days. The reason is that since this week, JDK 24 EA b22 is available for download, and as you can see in the preliminary JavaDocs, my very first addition to the official Java API is contained: Reader.of(CharSequence) !

You might wonder what’s so crazy about that, because (as you certainly know) I am a contributor to OpenJDK since many years. Well, yes, I did contribute to OpenJDK (alias “to Java”) for long time, but all my contributions where just “under the hood”. I have optimized execution performance, I improved JavaDocs, I added unit tests, and I refactored code. But this time, I added a complete new feature to the public API. It really feels so amazing to see that my work of the past few weeks now will help Java developers in their future projects to spare some microseconds and some kilobytes per call, and in sum, those approx. ten million developers (according to Oracle marketing) will sum up to considerable amounts of CO2 that my invention will spare!

Okay, so what actually is Reader.of(CharSequence) all about, how can you use it, and how does it spare resources?

I think you all know what the class StringReader is, and what to use it for: You need (for whatever reason) an implementation of the Reader interface, and the source is a String. At least that what it was made for decades ago. In fact, looking at the actual uses in 2024, more often than not the source isn’t a String actually, but is (mostly for performance reasons) a StringBuilder or StringBuffer, and sometimes (mostly for technical reasons) a CharBuffer. These classes all share one common interface, CharSequence, which is “the” interface of the class String, too. Unfortunately, StringReader is unable to accept CharSequence; it only accepts String. That’s too bad, because it means, most uses of StringReader actually perform an intermediate toString() operation, which creates a temporary copy of the full content on the heap – just to throw it away later! Creating this copy is anything but free! It imposes time to search a free place on the heap, to copy the content onto the heap, and to lateron GC (dispose and defragment) the otherwise unused copy in turn. Time is not just money – This operation costs power, and power costs (even these days) CO2!

Ontop of that, most (possibly all) uses of StringReader are single-threaded. I investigated for some time but could find not a single reason for accessing a StringReader in a multi-threaded fashion. Unfortunately, StringReader is thread-safe: It internally uses the synchronized keyword in every single method. Each time. For each single read in possibly a loop of thousand iterations! And yes, you guess right: synchronized a everything by fast. It slows down code considerably, for zero benefit! And: No, the JVM has no a trick to speed this up in the single-threaded use cases – that trick (“Biased Locking”) went away years ago and the result is that synchronized is slow again!

Imagine you are writing a RESTful web server which returns JSON on GET. JSON is nothing else but a character sequence. You build it from a non-trivial algorithm using a StringBuilder. That particular JSON unfortunately is non-cachable, as it contains information sent with the request or changing over time or provided by the real physical world. So the server possibly produces tens of thousands of StringBuilders per second and reads it using a StringReader. Could you imagine what happens to your performance? Thanks to the combination of both effects described earlier, you’re losing money with every other customer contacting your server. YOUR money, BTW.

This is exactly what happend in my latest commercial project, so I tried to get rid of StringReader. My first idea was to use Apache IO’s CharSequenceReader, which looks a bit old-school, but immediately got me rid of both effects instantly! The problem with Apache IO is that it is rather huge. Using lots of KBs of transitive dependencies just for one single use case didn’t sound like a smart option (but yes, this is the code actually in production still – at least unless JDK 24 is published in Q1/25). Also, the customer was not very pleased to adopt another third-party library into the game. And finally, the code of Apache IO is not really eagerly maintained; they do bug fixes, but they abstain from using modern Java APIs (not even using multi-release JARs). Some will hate me for writing this, but the actual change rate didn’t look like “stable”, it looked to “dead” – agreed, this is subject to my personal interpretation.

Being an enthusiastic Open Source committer since decades, and being an OpenJDK contributor since years, I had the idea to tackle the problem at its root: StringReader. So I proposed to provide a PR for a new public API, which was very much appreciated by the OpenJDK team. It was Alan Bateman himself (Group Lead of JDK Core Libraries) who came up with the proposal to have a static factory, which culminated in me posting a PR on Github about adding Reader.of(CharSequence). After accepting the mandatory CSR it recently got merged, and since JDK 24’s Eary Access Build 22 it is publicly available.

BTW, look at the implementation of that Reader’s bulk-read method. There is an ugly sequence of tricks to speed up performance. I will address this in a subsequent upcoming PR. Stay tuned!

So if you want to gain the performance benefit, here is what you need to do:

• Run your app on Java 24 EA b22+.
• Replace all occurances of new StringReader(x) and new CharSequenceReader(x) by Reader.of(x).
• If x ends with .toString() then remove that trailing .toString() – unless the left side of x is effectively not a CharSequence.
• Note: If you actually use multiple threads to access the Reader, don’t stick with StringReader, but simply surround your calls by a modern means of synchronization, like a Lock – locks are faster than synchronized.

Please exterminate StringReader but adopt Reader.of() ASAP!

I would be happy if you could report the results. Just leave a comment!

So far for today! PARTY ON!

The Generational Z Garbage Collector (ZGC)

The Generational Z Garbage Collector (GenZGC) in JDK 21 represents a significant evolution in Java’s approach to garbage collection, aiming to enhance application performance through more efficient memory management. This advancement builds upon the strengths of the Z Garbage Collector (ZGC) by introducing a generational approach to garbage collection within the JVM.

Design Rationale and Operational Mechanics

Generational Hypothesis: Generational ZGC leverages the “weak generational hypothesis,” which posits that most objects die young. By dividing the heap into young and old regions, GenZGC can focus its efforts on the young region where most objects become unreachable, thereby optimizing garbage collection efficiency and reducing CPU overhead

Heap Division and Collection Cycles: The heap is divided into two logical parts: the young generation and the old generation. Newly allocated objects are placed in the young generation, which is frequently scanned for garbage collection. Objects that survive several collection cycles are then promoted to the old generation, which is scanned less often. This division allows for more frequent collection of short-lived objects while reducing the overhead of collecting long-lived objects.

Performance Implications

Throughput and Latency Internal performance tests have shown that Generational ZGC offers about a 10% improvement in throughput over its single-generation predecessors in both JDK 17 and JDK 21, despite a slight regression in average latency measured in microseconds. However, the most notable improvement is observed in maximum pause times, with a 10-20% improvement in P99 pause times. This reduction in pause times significantly enhances the predictability and responsiveness of applications, particularly those requiring low latency.

Allocation Stalls

A crucial advantage of Generational ZGC is its ability to mitigate allocation stalls, which occur when the rate of object allocation outpaces the garbage collector’s ability to reclaim memory. This capability is particularly beneficial in high-throughput applications, such as those using Apache Cassandra, where Generational ZGC maintains performance stability even under high concurrency levels.

Practical Considerations and Adoption

Transition and Adoption: While JDK 21 introduces Generational ZGC, single-generation ZGC remains the default for now. Developers can opt into using Generational ZGC through JVM arguments (`-XX:+UseZGC -XX:+ZGenerational`). The plan is for Generational ZGC to eventually become the default, with single-generation ZGC being deprecated and removed. This phased approach allows developers to gradually adapt to the new system.

Diagnostic and Profiling Tools: For those evaluating or transitioning to Generational ZGC, tools like GC logging and JDK Flight Recorder (JFR) offer valuable insights into GC behavior and performance. GC logging, accessible via the `-Xlog` argument, and JFR data can be analyzed in JDK Mission Control (JMC) to assess garbage collection behavior and application performance implications.

Conclusion

Generational ZGC represents a significant step forward in Java’s garbage collection technology, offering improved throughput, reduced pause times, and enhanced overall application performance. Its design reflects a deep understanding of application memory management needs, particularly the efficient collection of short-lived objects. As Java applications continue to grow in complexity and scale, the adoption of Generational ZGC could be a pivotal factor in achieving the performance goals of modern, high-demand applications.

The transition from Java 17 to Java 21 heralds a new era of Java development, characterized by significant improvements in performance, security, and developer-friendly features. The API changes and enhancements discussed above are just the tip of the iceberg, with Java 21 offering a wealth of other features and improvements designed to cater to the evolving needs of modern application development.  As developers, embracing Java 21 and leveraging its new features and improvements can significantly impact the efficiency, performance, and security of Java applications. Whether it’s through the enhanced I/O capabilities, improved serialization exception handling, or the new Unicode support in the `Character` class, Java 21 offers a compelling upgrade path from Java 17, promising to enhance the Java ecosystem for years to come.  In conclusion, the evolution from Java 17 to Java 21 is a testament to the ongoing commitment to advancing Java as a language and platform. By exploring and adopting these new features, developers can ensure their Java applications remain cutting-edge, secure, and performant in the face of future challenges.

Cross-Context Dispatch reintroduced to Jetty-12

With the release of Jetty 12.0.8, we’re excited to announce the (re)implementation of a somewhat maligned and deprecated feature: Cross-Context Dispatch. This feature, while having been part of the Servlet specification for many years, has seen varied levels of use and support. Its re-introduction in Jetty 12.0.8, however, marks a significant step forward in our commitment to supporting the diverse needs of our users, especially those with complex legacy and modern web applications.

Understanding Cross-Context Dispatch

Cross-Context Dispatch allows a web application to forward requests to or include responses from another web application within the same Jetty server. Although it has been available as part of the Servlet specification for an extended period, it was deemed optional with Servlet 6.0 of EE10, reflecting its status as a somewhat niche feature.

Initially, Jetty 12 moved away from supporting Cross-Context Dispatch, driven by a desire to simplify the server architecture amidst substantial changes, including support for multiple environments (EE8, EE9, and EE10). These updates mean Jetty can now deploy web applications using either the javax namespace (EE8) or the jakarta namespace (EE9 and EE10), all using the latest optimized jetty core implementations of HTTP: v1, v2 or v3.

Reintroducing Cross-Context Dispatch

The decision to reintegrate Cross-Context Dispatch in Jetty 12.0.8 was influenced significantly by the needs of our commercial clients, some who still leveraging this feature in their legacy applications. Our commitment to supporting our clients’ requirements, including the need to maintain and extend legacy systems, remains a top priority.

One of the standout features of the newly implemented Cross-Context Dispatch is its ability to bridge applications across different environments. This means a web application based on the javax namespace (EE8) can now dispatch requests to, or include responses from, a web application based on the jakarta namespace (EE9 or EE10). This functionality opens up new pathways for integrating legacy applications with newer, modern systems.

Looking Ahead

The reintroduction of Cross-Context Dispatch in Jetty 12.0.8 is more than just a nod to legacy systems; it can be used as a bridge to the future of Java web development. By allowing for seamless interactions between applications across different Servlet environments, Jetty-12 opens the possibility of incremental migration away from legacy web applications.

Write a pure-Java microservice from scratch, without an application server nor any third party frameworks, tools, or IDE plugins — Just using JDK, Maven and JAX-RS aka Jakarta REST 3.1. This video series shows you the essential steps!

You asked, why I am not simply using the Jakarta EE 10 Core API. There are many answers in this video!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks!

This blog aims at giving some pointers in order to address the challenge related to the switch from `javax` to `jakarta` namespace. This is one of the biggest changes in Java of the latest 20 years. No doubt. The entire ecosystem is impacted. Not only Java EE or Jakarta EE Application servers, but also libraries of any kind (Jackson, CXF, Hibernate, Spring to name a few). For instance, it took Apache TomEE about a year to convert all the source code and dependencies to the new `jakarta` namespace.

This blog is written from the user perspective, because the shift from `javax` to `jakarta` is as impacting for application providers than it is for libraries or application servers. There have been a couple of attempts to study the impact and investigate possible paths to make the change as smooth as possible. 

The problem is harder than it appears to be. The `javax` package is of course in the import section of a class, but it can be in Strings as well if you use the Java Reflection API for instance. Using Byte Code tools like ASM also makes the problem more complex, but also service loader mechanisms and many more. We will see that there are many ways to approach the problem, using byte code, converting the sources directly, but none are perfect.

Bytecode enhancement approach

The first legitimate approach that comes to our mind is the byte code approach. The goal is to keep the `javax` namespace as much as possible and use bytecode enhancement to convert binaries.

Compile time

It is possible to do a post treatment on the libraries and packages to transform archives such as then are converted to `jakarta` namespace.

• https://maven.apache.org/plugins/maven-shade-plugin/[Maven Shade plugin]

The Maven shade plugin has the ability to relocate packages. While the primary purpose isn’t to move from `javax` to `jakarta` package, it is possible to use it to relocate small libraries when they aren’t ready yet. We used this approach in TomEE itself or in third party libraries such as Apache Johnzon (JSONB/P implementation).

Here is an example in TomEE where we use Maven Shade Plugin to transform the Apache ActiveMQ Client library https://github.com/apache/tomee/blob/main/deps/activemq-client-shade/pom.xml

This approach is not perfect, especially when you have a multi module library. For Instance, if you have a project with 2 modules, A depends on B. You can use the shade plugin to convert the 2 modules and publish them using a classifier. The issue then is when you need A, you have to exclude B so that you can include it manually with the right classifier.

We’d say it works fine but for simple cases because it breaks the dependency management in Maven, especially with transitive dependencies. It also break IDE integration because sources and javadoc won’t match.

• https://projects.eclipse.org/projects/technology.transformer[Eclipse Transformer]

The Eclipse Transformer is also a generic tool, but it’s been heavily developed for the `javax` to `jakarta` namespace change. It operates on resources such as

Simple resources:

• Java class files
• OSGi feature manifest files
• Properties files
• Service loader configuration files
• Text files (of several types: java source, XML, TLD, HTML, and JSP)

Container resources:

• Directories
• Java archives (JAR, WAR, RAR, and EAR files)
• ZIP archives

It can be configured using Java Properties files to properly convert Java Modules, classes, test resources. This is the approach we used for Apache TomEE 9.0.0-M7 when we first tried to convert to `jakarta`. It had limitation, so we had to then find tricks to solve issues. As it was converting the final distribution and not the individual artifacts, it was impossible for users to use Arquillian or the Maven plugin. They were not converted.

• https://github.com/apache/tomcat-jakartaee-migration[Apache Tomcat Migration tool]

This tool can operate on a directory or an archive (zip, ear, jar, war). It can migrate quite easily an application based on the set of specifications supported in Tomcat and a few more. It has the notion of profile so that you can ask it to convert more.

You can run it using the ANT task (within Maven or not), and there is also a command line interface to run it easily.

Deploy time

When using application server, it is sometimes possible to step in the deployment process and do the conversion of the binaries prior to their deployment.

• https://github.com/apache/tomcat-jakartaee-migration[Apache Tomcat/TomEE migration tool]

Mind that by default, the tool converts only what’s being supported by Apache Tomcat and a couple of other APIs. It does not convert all specifications supported in TomEE, like JAX RS for example. And Tomcat does not provide yet any way to configure it.

Runtime

We haven’t seen any working solution in this area. Of course, we could imagine a JavaAgent approach that converts the bytecode right when it gets loaded by the JVM. The startup time is seriously impacted, and it has to be done every time the JVM restarts or loads a class in a classloader. Remember that a class can be loaded multiple times in different classloaders.

Source code enhancement approach

This may sound like the most impacting but this is probably also the most secured one. We also strongly believe that embracing the change sooner is preferable rather than later. As mentioned, this is one of the biggest breaking change in Java of the last 20 years. Since Java EE moved to Eclipse to become Jakarta, we have noticed a change in the release cadence. Releases are not more frequent and more changes are going to happen. Killing the technical depth as soon as possible is probably the best when it’s so impacting.

There are a couple of tools we tried. There are probably more in the ecosystem, and also some in-house developments.

[IMPORTANT]

This is usually a one shoot operation. It won’t be perfect and no doubt it will require adjustment because there is no perfect tool that can handle all cases.

IntelliJ IDEA

IntelliJ IDEA added a refactoring capability to its IDE in order to convert sources to the new `jakarta` namespace. I haven’t tested it myself, but it may help to do the first big step when you don’t really master the scripting approach below.

Scripting approach

For simple case, and we used that approach to do most of the conversion in TomEE, you can create your own simple tool to convert sources. For instance, SmallRye does that with their MicroProfile implementations. Here is an example https://github.com/smallrye/smallrye-config/blob/main/to-jakarta.sh

Using basic Linux commands, it converts from `javax` to `jakarta` namespace and then the result is pushed to a dedicated branch. The benefit is that they have 2 source trees with different artifacts, the dependency management isn’t broken.

One source tree is the reference and they add to the script the necessary commands to convert additional things on demand.

• https://projects.eclipse.org/projects/technology.transformer[Eclipse Transformer]

Because the Eclipse Transformer can operate on text files, it can be easily used to migrate the sources from `javax` to `jakarta` namespace.

Producing converted artifacts for applications for consumption

Weather you are working on Open Source or not, someone will consume your artifacts. If you are using Maven for example, you may ask yourself what option is the best especially if you maintain the 2 branches `javax` and `jakarta`.

[NOTE]

It does not matter if you use the bytecode or the source code approach.

Updating version or artifactId

This is probably the more practical solution. Some project like Arquillian for example decided to go using a different artifact name (-jakarta suffix) because the artifact is the same and solves the same problem, so why bringing a technical concerned into the name? I’m more in favor of using the version to mark the namespace change. It is somehow an major API change that I’d rather emphasize using a major version update.

[IMPORTANT]

Mind that this only works if both `javax` and `jakarta` APIs are backward compatible. Otherwise, it won’t work

Using Maven classifiers

This is not an option we would recommend. Unfortunately some of our dependencies use this approach and it has many drawbacks. It’s fine for a quick test, but as I mentioned previously, it badly impacts how Maven works. If you pull a transformed artifact, you may get a transitive and not transformed dependency. This is the case for multi module project as well.

Another painful side effect is that javadoc and sources are still linked to the original artifact, so you will have a hard time to debug in the IDE.

Conclusion

We tried the bytecode approach ourselves in TomEE with the hope we could avoid maintaining 2 source trees, one for `javax` and the other one for `jakarta` namespace. Unfortunately, as we have seen before the risk is too important and there are too many edge cases not covered. Apache TomEE runs about 60k tests (including TCK) and our confidence wasn’t good enough. Even though the approach has some benefits and can work for simple use cases, like converting a small utility tool, it does not fit in our opinion for real applications.

The post Moving from javax to jakarta namespace appeared first on Tomitribe.

Now that Jetty 12.0.1 is released to Maven Central, we’ve started to get a few questions about where some artifacts are, or when we intend to release them (as folks cannot find them).

Things have change with Jetty, starting with the 12.0.0 release.

First, is that our historical versioning of <servlet_support>.<major>.<minor> is no longer being used.

With Jetty 12, we are now using a more traditional <major>.<minor>.<patch> versioning scheme for the first time.

Also new in Jetty 12 is that the Servlet layer has been separated away from the Jetty Core layer.

The Servlet layer has been moved to the new Environments concept introduced with Jetty 12.

This means the old Servlet specific artifacts have been moved to environment specific locations both in terms of Java namespace and also their Maven Coordinates.

Example:

Jetty 11 – Using Servlet 5
Maven Coord: org.eclipse.jetty:jetty-servlet
Java Class: org.eclipse.jetty.servlet.ServletContextHandler

Jetty 12 – Using Servlet 6
Maven Coord: org.eclipse.jetty.ee10:jetty-ee10-servlet
Java Class: org.eclipse.jetty.ee10.servlet.ServletContextHandler

We have a migration document which lists all of the migrated locations from Jetty 11 to Jetty 12.

This new versioning and environment features built into Jetty means that new major versions of Jetty are not as common as they have been in the past.

The results of the 2023 Jakarta EE Developer Survey are now available! For the sixth year in a row, we’ve reached out to the enterprise Java community to ask about their preferences and priorities for cloud native Java architectures, technologies, and tools, their perceptions of the cloud native application industry, and more.

From these results, it is clear that open source cloud native Java is on the rise following the release of Jakarta EE 10.The number of respondents who have migrated to Jakarta EE continues to grow, with 60% saying they have already migrated, or plan to do so within the next 6-24 months. These results indicate steady growth in the use of Jakarta EE and a growing interest in cloud native Java overall.

When comparing the survey results to 2022, usage of Jakarta EE to build cloud native applications has remained steady at 53%. Spring/Spring Boot, which relies on some Jakarta EE specifications, continues to be the leading Java framework in this category, with usage growing from 57% to 66%. 

Since the September 2022 release, Jakarta EE 10 usage has grown to 17% among survey respondents. This community-driven release is attracting a growing number of application developers to adopt Jakarta EE 10 by offering new features and updates to Jakarta EE. An equal number of developers are running Jakarta EE 9 or 9.1 in production, while 28% are running Jakarta EE 8. That means the increase we are seeing in the migration to Jakarta EE is mostly due to the adoption of Jakarta EE 10, as compared to Jakarta EE 9/9.1 or Jakarta EE 8.

The Jakarta EE Developer Survey also gives us a chance to get valuable feedback on features from the latest Jakarta EE release, as well as what direction the project should take in the future. 

Respondents are most excited about Jakarta EE Core Profile, which was introduced in the Jakarta EE 10 release as a subset of Web Profile specifications designed for microservices and ahead-of-time compilation. When it comes to future releases, the community is prioritizing better support for Kubernetes and microservices, as well as adapting Java SE innovations to Jakarta EE — a priority that has grown in popularity since 2022. This is a good indicator that the Jakarta EE 11 release plan is on the right direction by adopting new Java SE 21 features.

2,203 developers, architects, and other tech professionals participated in the survey, a 53% increase from last year. This year’s survey was also available in Chinese, Japanese, Spanish & Portuguese, making it easier for Java enthusiasts around the world to share their perspectives.  Participation from the Chinese Jakarta EE community was particularly strong, with over 27% of the responses coming from China. By hearing from more people in the enterprise Java space, we’re able to get a clearer picture of what challenges developers are facing, what they’re looking for, and what technologies they are using. Thank you to everyone who participated! 

Learn More

We encourage you to download the report for a complete look at the enterprise Java ecosystem. 

If you’d like to get more information about Jakarta EE specifications and our open source community, sign up for one of our mailing lists or join the conversation on Slack. If you’d like to participate in the Jakarta EE community, learn how to get started on our website.

Looking at the web, we don’t see many articles talking about Contexts Dependency Injection’s best practices. Hence, I have made the decision to discuss the utilization of Contexts Dependency Injection (CDI) using best practices, providing a comprehensive guide on its implementation.

The CDI is a Jakarta specification in the Java ecosystem to allow developers to use dependency injection, managing contexts, and component injection in an easier way. The article https://www.baeldung.com/java-ee-cdi defines the CDI as follows:

CDI turns DI into a no-brainer process, boiled down to just decorating the service classes with a few simple annotations, and defining the corresponding injection points in the client classes.

If you want to learn the CDI concepts you can read Baeldung’s post and Otavio Santana’s post. Here, in this post, we will focus on the best practices topic.

In fact, CDI is a powerful framework and allows developers to use Dependency Injection (DI) and Inversion of Control (IoC). However, we have one question here. How tightly do we want our application to be coupled with the framework? Note that I’m not talking you cannot couple your application to a framework, but you should think about it, think about the coupling level, and think about the tradeoffs. For me, coupling an application to a framework is not wrong, but doing it without thinking about the coupling level and the cost and tradeoffs is wrong.

It is impossible to add a framework to your application without minimally coupling your application. Even though your application does not have a couple expressed in the code, probably you have a behavioral coupling, that is, a behavior in your application depends on a framework’s behavior, and in some cases, you can not guarantee that other framework will provide a similar behavior, in case of changes.

Best Practices for Injecting Dependencies

When writing code in Java, we often create classes that rely on external dependencies to perform their tasks. To achieve this using CDI, we employ the @Inject annotation, which allows us to inject these dependencies. However, it’s essential to be mindful of whether we are making the class overly dependent on CDI for its functionality, as it may limit its usability without CDI. Hence, it’s crucial to carefully consider the tightness of this dependency. As an illustration, let’s examine the code snippet below. Here, we encounter a class that is tightly coupled to CDI in order to carry out its functionality.

public class ImageRepository {
    @Inject
    private StorageProvider storageProvider;

    public void saveImage(File image){
        //Validate the file to check if it is an image.
        //Apply some logic if needed
        storageProvider.save(image);
    }
}

As you can see the class ImageRepository has a dependency on StorageProvider, that is injected via CDI annotation. However, the storageProvider variable is private and we don’t have setter method or a constructor that allows us to pass this dependency by the constructor. It means this class cannot work without a CDI context, that is, the ImageRepository is tightly coupled to CDI.

This coupling doesn’t provide any benefits for the application, instead, it only causes harm both to the application itself and potentially to the testing of this class.

Look at the code refactored to reduce the couple to CDI.

public class ImageRepository implements Serializable {

    private StorageProvider storageProvider;

    @Inject
    public ImageRepository(StorageProvider storageProvider){
        this.storageProvider = storageProvider;
    }

    public void saveImage(File image){
        //Validate the file to check if it is an image.
        //Apply some logic if needed
        storageProvider.save(image);
    }
}

As you can see, the ImageRepository class has a constructor that receives the StorageProvider as a constructor argument. This approach follows what is said in the Clean Code book.

“True Dependency Injection goes one step further. The class takes no direct steps to resolve its dependencies; it is completely passive. Instead, it provides setter methods or constructor arguments (or both) that are used to inject the dependencies.”

(from “Clean Code: A Handbook of Agile Software Craftsmanship” by Martin Robert C.)

Without a constructor or a setter method, the injection depends on the CDI. However, we still have one question about this class. The class has a CDI annotation and depends on the CDI to be compiled. I’m not saying it is always a problem, but it can be a problem, especially if you are writing a framework. Coupling a framework with another framework can be a problem in cases you want to use your framework with another mutually exclusive one. In general, it should be avoided by frameworks. Thus, how can we fully decouple the ImageRepository class from CDI?

CDI Producer Method

The CDI producer is a source of an object that can be used to be injected by CDI. It is like a factor of a type of object. Look at the code below:

public class ImageRepositoryProducer {

    @Produces
    public ImageRepository createImageRepository(){
        StorageProvider storageProvider = CDI.current().select(StorageProvider.class).get();
        return new ImageRepository(storageProvider);
    }
}

Please note that we are constructing just one object, but the StorageProvider‘s object is read by CDI. You should avoid constructing more than one object within a producer method, as this interlinks the construction of these objects and may lead to complications if you intend to designate distinct scopes for them. You can create a separated producer method to produce the StorageProvider.

This is the ImageRepository class refactored.

public class ImageRepository implements Serializable {

    private StorageProvider storageProvider;

    public ImageRepository(StorageProvider storageProvider){
        this.storageProvider = storageProvider;
    }

    public void saveImage(File image){
        //Validate the file to check if it is an image.
        //Apply some logic if needed
        storageProvider.save(image);
    }
}

Please note that the ImageRepository class does not know anything about the CDI, and is fully decoupled from CDI. The codes about the CDI are inside the ImageRepositoryProducer, which can be extracted to another module if needed.

CDI Interceptor

The CDI Interceptor is a very cool feature of CDI that provides a nice CDI-based way to work with cross-cutting tasks (such as auditing). This is a little definition said in my book:

“A CDI interceptor is a class that wraps the call to a method — this method is called target method — that runs its logic and proceeds the call either to the next CDI interceptor if it exists, or the target method.”

(from “Jakarta EE for Java Developers” by Rhuan Rocha.)

The purpose of this article is not to discuss what a CDI interceptor is, but to discuss CDI best practices. So if you want to read more about CDI interceptor, check out the book Jakarta EE for Java Developers.

As said, the CDI interceptor is very interesting. I am quite fond of this feature and have incorporated it into numerous projects. However, using this feature comes with certain trade-offs for the application.

When you use the CDI interceptor you couple the class to the CDI, because you should be annotating the class with a custom annotation that is a interceptor binding. Look at the example below shown on the Jakarta EE for Java Developers book:

@ApplicationScopedpublic class SecuredBean{
   @Authentication
   public String generateText(String username) throws AutenticationException{
       return "Welcome "+username;
   }
}

As you can see we should define a scope, as it should be a bean managed by CDI, and you should be annotating the class with the interceptor binding. Hence, if you eliminate CDI from your application, the interceptor’s logic won’t execute, and the class won’t be compiled. With this, your application has a behavioral coupling, and a dependency on the CDI lib jar to compile.

As said, it is not necessarily bad, however, you should think if it is a problem in your context.

CDI Event

The CDI Event is a great feature within the CDI framework that I have employed extensively in various applications. This functionality provides the implementation of the Observer Pattern, enabling us to emit events that are then observed by observers who execute tasks asynchronously. However, if we add the CDI codes inside our class to emit events we will couple the class to the CDI. Again, this is not an error, but you should be sure it is not a problem with your solution. Look at the example below.

import jakarta.enterprise.event.Event;

public class User{

 private Event<Email> emailEvent;

 public User(Event<Email> emailEvent){
   this.emailEvent = emailEvent;
 }

 public void register(){
   //logic
   emailEvent.fireAsync(Email.of(from, to, subject, content));
 }
}

Note we are receiving the Event class, which is from CDI, to emit the event. It means this class is coupled to CDI and depends on it to work. One way to avoid it is creating your own class to emit the event, and abstract the details about what is the mechanism (CDI or other) that is emitting the event. Look at the example below.

import net.rhuan.example.EventEmitter;

public class User{

 private EventEmiter<Email> emailEventEmiter;

 public User(EventEmiter<Email> emailEventEmiter){
   this.emailEventEmiter = emailEventEmiter;
 }

 public void register(){
   //logic
   emailEventEmiter.emit(Email.of(from, to, subject, content));
 }
}

Now, your class is agnostic to the emitter of the event. You can use CDI or others, according to the EventEmiter implementation.

Conclusion

The CDI is an amazing specification from Jakarta EE widely used in many Java frameworks and Java applications. Carefully determining the degree of integration between our application and the framework holds immense significance. This intentional decision becomes an important factor in proactively mitigating challenges during the solution’s evolution, especially when working on the development of a framework.

If you have a question or want to share your thoughts, feel free to add comments or send me messages about it.

In this post, I will talk to you about what the Apache Camel is. It is a brief introduction before I starting to post practical content. Thus, let’s go to understand what this framework is.

Apache Camel is an open source Java integration framework that allows different applications to communicate with each other efficiently. It provides a platform for integrating heterogeneous software systems. Camel is designed to make application integration easy, simplifying the complexity of communication between different systems.

Apache Camel is written in Java and can be run on a variety of platforms, including Jakarta EE application servers and OSGi-based application containers, and can runs inside cloud environments using Spring Boot or Quarkus. Camel also supports a wide range of network protocols and message formats, including HTTP, FTP, SMTP, JMS, SOAP, XML, and JSON.

Camel uses the Enterprise Integration Patterns (EIP) pattern to define the different forms of integration. EIP is a set of commonly used design patterns in system integration. Camel implements many of these patterns, making it a powerful tool for integration solutions.

Additionally, Camel has a set of components that allow it to integrate with different systems. The components can be used to access different resources, such as databases, web services, and message systems. Camel also supports content-based routing, which means it can route messages based on their content.

Camel is highly configurable and extensible, allowing developers to customize its functionality to their needs. It also supports the creation of integration routes at runtime, which means that routes can be defined and changed without the need to restart the system.

In summary, Camel is a powerful and flexible tool for software system integration. It allows different applications to communicate efficiently and effectively, simplifying the complexity of system integration. Camel is a reliable and widely used framework that can help improve the efficiency and effectiveness of system integration in a variety of environments.

If you want to start using this framework you can access the documentation at the site. It’s my first post about the Apache Camel and will post more practical content about this amazing framework.

Community Day at EclipseCon 2022 was held in person on Monday, October 24 in Ludwigsburg, Germany. Community Day has always been a great event for Eclipse working groups and project teams, including Jakarta EE/MicroProfile. This year was no exception. A number of great sessions were delivered from prominent folks in the community. The following are the details including session materials. The agenda can still be found here. All the materials can be found here.

Jakarta EE Community State of the Union

The first session of the day was a Jakarta EE community state of the union delivered by Tanja Obradovic, Ivar Grimstad and Shabnam Mayel. The session included a quick overview of Jakarta EE releases, how to get involved in the work of producing the specifications, a recap of the important Jakarta EE 10 release and as well as a view of what’s to come in Jakarta EE 11. The slides are embedded below and linked here.

Jakarta Concurrency – What’s Next

Payara CEO Steve Millidge covered Jakarta Concurrency. He discussed the value proposition of Jakarta Concurrency, the innovations delivered in Jakarta EE 10 (including CDI based @Asynchronous, @ManagedExecutorDefinition, etc) and the possibilities for the future (including CDI based @Schedule, @Lock, @MaxConcurrency, etc). The slides are embedded below and linked here. There are some excellent code examples included.

Jakarta Security – What’s Next

Werner Keil covered Jakarta Security. He discussed what’s already done in Jakarta EE 10 (including OpenID Connect support) and everything that’s in the works for Jakarta EE 11 (including CDI based @RolesAllowed). The slides are embedded below and linked here.

Jakarta Data – What’s Coming

IBM’s Emily Jiang kindly covered Jakarta Data. This is a brand new specification aimed towards Jakarta EE 11. It is a higher level data access abstraction similar to Spring Data and DeltaSpike Data. It encompasses both Jakarta Persistence (JPA) and Jakarta NoSQL. The slides are embedded below and linked here. There are some excellent code examples included.

MicroProfile Community State of the Union

Emily also graciously delivered a MicroProfile state of the union. She covered what was delivered in MicroProfile 5, including alignment with Jakarta EE 9.1. She also discussed what’s coming soon in MicroProfile 6 and beyond, including very clear alignment with the Jakarta EE 10 Core Profile. The slides are embedded below and linked here. There are some excellent technical details included.

MicroProfile Telemetry – What’s Coming

Red Hat’s Martin Stefanko covered MicroProfile Telemetry. Telemetry is a brand new specification being included in MicroProfile 6. The specification essentially supersedes MicroProfile Tracing and possibly MicroProfile Metrics too in the near future. This is because the OpenTracing and OpenCensus projects merged into a single project called OpenTelemetry. OpenTelemetry is now the de facto standard defining how to collect, process, and export telemetry data in microservices. It makes sense that MicroProfile moves forward with supporting OpenTelemetry. The slides are embedded below and linked here. There are some excellent technical details and code examples included.

See You There Next Time?

Overall, it was an honor to organize the Jakarta EE/MicroProfile agenda at EclipseCon Community Day one more time. All speakers and attendees should be thanked. Perhaps we will see you at Community Day next time? It is a great way to hear from some of the key people driving Jakarta EE and MicroProfile. You can attend just Community Day even if you don’t attend EclipseCon. The fee is modest and includes lunch as well as casual networking.

An impression of JFall by yours truly.

keynote

Sold out!

Packet room!

Very nice first keynote speaker by Saby Sengupta about the path to transform.
He is a really nice storyteller. He had us going.

Dutch people, wooden shoes, wooden hat, would not listen

• Saby

lol

Get the answer to three why questions. If the answers stop after the first why. It may not be a good idea.

This great first keynote is followed by the very well known Venkat Subramaniam about The Art of Simplicity.

The question is not what can we add? But What can we remove?

Simple fails less

Simple is elegant

All in al a great keynote! Loved it.

Design Patterns in the light of Lambdas

By Venkat Subramaniam

The GOF are kind of the grand parents of our industry. The worst thing they have done is write the damn book.
— Venkat

The quote is in the context of that writing down grandmas fantastic recipe does not work as it is based on the skill of grandma and not the exact amount of the ingredients.

The cleanup is the responsibility of the Resource class. Much better than asking developers to take care of it. It will be forgotten!

The more powerful a language becomes the less we need to talk about patterns. Patterns become practices we use. We do not need to put in extra effort.

I love his way of presenting, but this is the one of those times - I guess - that he is hampered by his own succes. The talk did not go deep into stuff. During his talk I just about covered 5 not too difficult subjects. I missed his speed and depth.

Still a great talk though.

lunch

Was actually very nice!

NLJUG update keynote

The Java Magazine was mentioned we (as Editors) had to shout for that!

Please contact me (@ivonet) if you have ambitions to either be an author or maybe even as a fellow editor of the magazine. We are searching for a new Editor now.

Then the voting for the Innovation Awards.

I kinda missed the next keynote by ING because I was playing with a rubix cube and I did not really like his talk

jakarta EE 10 platform

by Ivar Grimstad

Ivar talks about the specification of Jakarta EE.

To create a lite version of CDI it is possible to start doing things at build time and facilitate other tools like GraalVM and Quarkus.

He gives nice demos on how to migrate code to work in de jakarta namespace.

To start your own Jakarta EE application just go to start.jakarta.ee en follow the very simple UI instructions

I am very proud to be the creator of that UI. Thanks, Ivar for giving me a shoutout for that during your talk. More cool stuff will follow soon.

Be prepared to do some namespace changes when moving from Java EE 8 to Jakarta EE.

All slides here

conclusion

I had a fantastic day. For me, it is mainly about the community and seeing all the people I know in the community. I totally love the vibe of the conference and I think it is one of the best organized venues.

See you at JSpring.

Ivo.

The results of the 2022 Jakarta EE Developer Survey are very telling about the current state of the enterprise Java developer community. They point to increased confidence about Jakarta EE and highlight how far Jakarta EE has grown over the past few years.

Strong Turnout Helps Drive Future of Jakarta EE

The fifth annual survey is one of the longest running and best-respected surveys of its kind in the industry. This year’s turnout was fantastic: From March 9 to May 6, a total of 1,439 developers responded. 

This is great for two reasons. First, obviously, these results help inform the Java ecosystem stakeholders about the requirements, priorities and perceptions of enterprise developer communities. The more people we hear from, the better picture we get of what the community wants and needs. That makes it much easier for us to make sure the work we’re doing is aligned with what our community is looking for. 

The other reason is that it helps us better understand how the cloud native Java world is progressing. By looking at what community members are using and adopting, what their top goals are and what their plans are for adoption, we can better understand not only what we should be working on today, but tomorrow and for the future of Jakarta EE. 

Findings Indicate Growing Adoption and Rising Expectations

Some of the survey’s key findings include:

• Jakarta EE is the basis for the top frameworks used for building cloud native applications.
• The top three frameworks for building cloud native applications, respectively, are Spring/Spring Boot, Jakarta EE and MicroProfile, though Spring/Spring Boot lost ground this past year. It’s important to note that Spring/SpringBoot relies on Jakarta EE developments for its operation and is not competitive with Jakarta EE. Both are critical ingredients to the healthy enterprise Java ecosystem. 
• Jakarta EE 9/9.1 usage increased year-over-year by 5%.
• Java EE 8, Jakarta EE 8, and Jakarta EE 9/9.1 hit the mainstream with 81% adoption. 
• While over a third of respondents planned to adopt, or already had adopted Jakarta EE 9/9.1, nearly a fifth of respondents plan to skip Jakarta EE 9/9.1 altogether and adopt Jakarta EE 10 once it becomes available. 
• Most respondents said they have migrated to Jakarta EE already or planned to do so within the next 6-24 months.
• The top three community priorities for Jakarta EE are:
  • Native integration with Kubernetes (same as last year)
  • Better support for microservices (same as last year)
  • Faster support from existing Java EE/Jakarta EE or cloud vendors (new this year)

Two of the results, when combined, highlight something interesting:

• 19% of respondents planned to skip Jakarta EE 9/9.1 and go straight to 10 once it’s available 
• The new community priority — faster support from existing Java EE/Jakarta EE or cloud vendors — really shows the growing confidence the community has in the ecosystem

After all, you wouldn’t wait for a later version and skip the one that’s already available, unless you were confident that the newer version was not only going to be coming out on a relatively reliable timeline, but that it was going to be an improvement. 

And this growing hunger from the community for faster support really speaks to how far the ecosystem has come. When we release a new version, like when we released Jakarta EE 9, it takes some time for the technology implementers to build the product based on those standards or specifications. The community is becoming more vocal in requesting those implementers to be more agile and quickly pick up the new versions. That’s definitely an indication that developer demand for Jakarta EE products is growing in a healthy way. 

Learn More

If you’d like to learn more about the project, there are several Jakarta EE mailing lists to sign up for. You can also join the conversation on Slack. And if you want to get involved, start by choosing a project, sign up for its mailing list and start communicating with the team.

The Jakarta EE Ambassadors are thrilled to see Jakarta EE 10 being released! This is a milestone release that bears great significance to the Java ecosystem. Jakarta EE 8 and Jakarta EE 9.x were important releases in their own right in the process of transitioning Java EE to a truly open environment in the Eclipse Foundation. However, these releases did not deliver new features. Jakarta EE 10 changes all that and begins the vital process of delivering long pending new features into the ecosystem at a regular cadence.

There are quite a few changes that were delivered – here are some key themes and highlights:

• CDI Alignment
  • @Asynchronous in Concurrency
  • Better CDI support in Batch
• Java SE Alignment
  • Support for Java SE 11, Java SE 17
  • CompletionStage, ForkJoinPool, parallel streams in Concurrency
  • Bootstrap APIs for REST
• Closing standardization gaps
  • OpenID Connect support in Security, @ManagedExecutorDefinition, UUID as entity keys, more SQL support in Persistence queries, multipart/form-data support in REST, @ClientWindowScoped in Faces, pure Java Faces views
  • CDI Lite/Core Profile to enable next generation cloud native runtimes – MicroProfile will likely align with CDI Lite/Jakarta EE Core
• Deprecation/removal
  • @Context annotation in REST, EJB Entity Beans, embeddable EJB container, deprecated Servlet/Faces/CDI features

While there are many features that we identified in our Jakarta EE 10 Contribution Guide that did not make it yet, this is still a very solid release that everyone in the Java ecosystem will benefit from, including Spring, MicroProfile and Quarkus. You can see here what was delivered, what’s on the way and what gaps still remain. You can try Jakarta EE 10 out now using compatible implementations like GlassFish, Payara, WildFly and Open Liberty. Jakarta EE 10 is proof in the pudding that the community, including major stakeholders, has not only made it through the transition to the Eclipse Foundation but now is beginning to thrive once again.

Many Ambassadors helped make this release a reality such as Arjan Tijms, Werner Keil, Markus Karg, Otavio Santana, Ondro Mihalyi and many more. The Ambassadors will now focus on enabling the community to evangelize Jakarta EE 10 including speaking, blogging, trying out implementations, and advocating for real world adoption. We will also work to enable the community to continue to contribute to Jakarta EE by producing an EE 11 Contribution Guide in the coming months. Please stay tuned and join us.

Jakarta EE is truly moving forward – the next phase of the platform’s evolution is here!

Getting started with Jakarta EE just became even easier!

Get started

• Java EE /Jakarta EE - Initializr

Hot new Update!

Moved from the Apache 2 license to the Eclipse Public License v2 for the newest version of the archetype as described below.
As a start for a possible collaboration with the Eclipse start project.

New Archetype with JakartaEE 9

JakartaEE 9 + Payara 5.2022.2 + MicroProfile 4.1 running on Java 17

• And the docker image is also ready for x86_64 (amd64) AND aarch64 (arm64/v8) architectures!

FOSDEM took place February 5-6. The European based event is one of the most significant gatherings worldwide focused on all things Open Source. Named the “Friends of OpenJDK”, in recent years the event has added a devroom/track dedicated to Java. The effort is lead by my friend and former colleague Geertjan Wielenga. Due to the pandemic, the 2022 event was virtual once again. I delivered a couple of talks on Jakarta EE as well as Diversity & Inclusion.

Fundamentals of Diversity & Inclusion for Technologists

I opened the second day of the conference with my newest talk titled “Fundamentals of Diversity and Inclusion for Technologists”. I believe this is an overdue and critically important subject. I am very grateful to FOSDEM for accepting the talk. The reality for our industry remains that many people either have not yet started or are at the very beginning of their Diversity & Inclusion journey. This talk aims to start the conversation in earnest by explaining the basics. Concepts covered include unconscious bias, privilege, equity, allyship, covering and microaggressions. I punctuate the topic with experiences from my own life and examples relevant to technologists. The slides for the talk are available on SpeakerDeck. The video for the talk is now posted on YouTube.

Jakarta EE – Present and Future

Later the same day, I delivered my fairly popular talk – “Jakarta EE – Present and Future”. The talk is essentially a state of the union for Jakarta EE. It covers a little bit of history, context, Jakarta EE 8, Jakarta EE 9/9.1 as well as what’s ahead for Jakarta EE 10. One key component of the talk is the importance and ways of direct developer contributions into Jakarta EE, if needed with help from the Jakarta EE Ambassadors. Jakarta EE 10 and the Jakarta Core Profile should bring an important set of changes including to CDI, Jakarta REST, Concurrency, Security, Faces, Batch and Configuration. The slides for the talk are available on SpeakerDeck. The video for the talk is now posted on YouTube.

I am very happy to have had the opportunity to speak at FOSDEM. I hope to contribute again in the future.

Infinispan 10+ uses Log4j version 2.0+ and can be affected by vulnerability CVE-2021-44228, which has a 10.0 CVSS score. The first fixed Log4j version is 2.15.0.
So, until official patch is coming, - you can update used logger version to the latest in few simple steps

• Download Log4j version 2.15.0: https://www.apache.org/dyn/closer.lua/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.zip
• Unpack distributive
• Replace affected libraries

wget https://downloads.apache.org/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.zip
unzip apache-log4j-2.15.0-bin.zip

cd /opt/infinispan-server-10.1.8.Final/lib/

rm log4j-*.jar
cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-api-2.15.0.jar ./
cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-core-2.15.0.jar ./
cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-jul-2.15.0.jar ./
cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-slf4j-impl-2.15.0.jar ./

Please, note - patch above is not official, but according to initial tests it works with no issues

In the previous post, we saw how to use the built-in ‘tomcat-users.xml’ identity store with Apache TomEE. While this identity store is inherited from Tomcat and integrated into Jakarta Security implementation in TomEE, this is usually good for development or simple deployments, but may appear too simple or restrictive for production environments. 

This blog will focus on how to implement your own identity store. TomEE can use LDAP or JDBC identity stores out of the box. We will try them out next time.

Let’s say you have your own file store or your own data store like an in-memory data grid, then you will need to implement your own identity store.

What is an identity store?

An identity store is a database or a directory (store) of identity information about a population of users that includes an application’s callers.

In essence, an identity store contains all information such as caller name, groups or roles, and required information to validate a caller’s credentials.

How to implement my own identity store?

This is actually fairly simple with Jakarta Security. The only thing you need to do is create an implementation of `jakarta.security.enterprise.identitystore.IdentityStore`. All methods in the interface have default implementations. So you only have to implement what you need.

public interface IdentityStore {
   Set DEFAULT_VALIDATION_TYPES = EnumSet.of(VALIDATE, PROVIDE_GROUPS);

   default CredentialValidationResult validate(Credential credential) {
   }

   default Set getCallerGroups(CredentialValidationResult validationResult) {
   }

   default int priority() {
   }

   default Set validationTypes() {
   }

   enum ValidationType {
       VALIDATE, PROVIDE_GROUPS
   }
}

By default, an identity store is used for both validating user credentials and providing groups/roles for the authenticated user. Depending on what #validationTypes() will return, you will have to implement #validate(…) and/or #getCallerGroups(…)

#getCallerGroups(…) will receive the result of #valide(…). Let’s look at a very simple example:

@ApplicationScoped
public class TestIdentityStore implements IdentityStore {

   public CredentialValidationResult validate(Credential credential) {

       if (!(credential instanceof UsernamePasswordCredential)) {
           return INVALID_RESULT;
       }

       final UsernamePasswordCredential usernamePasswordCredential = (UsernamePasswordCredential) credential;
       if (usernamePasswordCredential.compareTo("jon", "doe")) {
           return new CredentialValidationResult("jon", new HashSet<>(asList("foo", "bar")));
       }

       if (usernamePasswordCredential.compareTo("iron", "man")) {
           return new CredentialValidationResult("iron", new HashSet<>(Collections.singletonList("avengers")));
       }

       return INVALID_RESULT;
   }

}

In this simple example, the identity store is hardcoded. Basically, it knows only 2 users, one of them has some roles, while the other has another set of roles.

You can easily extend this example and query a local file, or an in-memory data grid if you need. Or use JPA to access your relational database.

IMPORTANT: for TomEE to pick it up and use it in your application, the identity store must be a CDI bean.

The complete and runnable example is available under https://github.com/apache/tomee/tree/master/examples/security-custom-identitystore

The post Custom Identity Store with Jakarta Security in TomEE appeared first on Tomitribe.

Wildfly provides great out of the box load balancing support by Undertow and modcluster subsystems
Unfortunately, in case HTTP headers size is huge enough (close to 16K), which is so actual in JWT era - pity error happened:

ERROR [io.undertow.proxy] (default I/O-10) UT005028: Proxy request to /ee-jax-rs-examples/clusterdemo/serverinfo failed: java.io.IOException: java.nio.BufferOverflowException
 at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:771)
 at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646)
 at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561)
 at io.undertow.client.ajp.AjpClientExchange.invokeReadReadyCallback(AjpClientExchange.java:203)
 at io.undertow.client.ajp.AjpClientConnection.initiateRequest(AjpClientConnection.java:288)
 at io.undertow.client.ajp.AjpClientConnection.sendRequest(AjpClientConnection.java:242)
 at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561)
 at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35)
 at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:815)
...
Caused by: java.nio.BufferOverflowException
 at java.nio.Buffer.nextPutIndex(Buffer.java:521)
 at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:297)
 at io.undertow.protocols.ajp.AjpUtils.putString(AjpUtils.java:52)
 at io.undertow.protocols.ajp.AjpClientRequestClientStreamSinkChannel.createFrameHeaderImpl(AjpClientRequestClientStreamSinkChannel.java:176)
 at io.undertow.protocols.ajp.AjpClientRequestClientStreamSinkChannel.generateSendFrameHeader(AjpClientRequestClientStreamSinkChannel.java:290)
 at io.undertow.protocols.ajp.AjpClientFramePriority.insertFrame(AjpClientFramePriority.java:39)
 at io.undertow.protocols.ajp.AjpClientFramePriority.insertFrame(AjpClientFramePriority.java:32)
 at io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:603)
 at io.undertow.server.protocol.framed.AbstractFramedChannel.flush(AbstractFramedChannel.java:742)
 at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:735)
 at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:267)
 at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:244)
 at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79)
 at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:754)

The same request directly to backend server works well. Tried to play with ajp-listener and mod-cluster filter "max-*" parameters, but have no luck.

Possible solution here is switch protocol from AJP to HTTP which can be bit less effective, but works well with big headers:

/profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=listener, value=default)

As part of the Jakarta EE Quickstart Tutorials on YouTube, I’ve now created a five-part series to create a Jakarta EE CRUD API. Within the videos, I’m demonstrating how to start using Jakarta EE for your next application. Given the Liberty Maven Plugin and MicroShed Testing, the endpoints are developed using the TDD (Test Driven Development) technique.

The following technologies are used within this short series: Java 11, Jakarta EE 8, Open Liberty, Derby, Flyway, MicroShed Testing & JUnit 5

Part I: Introduction to the application setup

This part covers the following topics:

• Introduction to the Maven project skeleton
• Flyway setup for Open Liberty
• Derby JDBC connection configuration
• Basic MicroShed Testing setup for TDD

Part II: Developing the endpoint to create entities

This part covers the following topics:

• First JAX-RS endpoint to create Person entities
• TDD approach using MicroShed Testing and the Liberty Maven Plugin
• Store the entities using the EntityManager

Part III: Developing the endpoints to read entities

This part covers the following topics:

• Develop two JAX-RS endpoints to read entities
• Read all entities and by its id
• Handle non-present entities with a different HTTP status code

Part IV: Developing the endpoint to update entities

This part covers the following topics:

• Develop the JAX-RS endpoint to update entities
• Update existing entities using HTTP PUT
• Validate the client payload using Bean Validation

Part V: Developing the endpoint to delete entities

This part covers the following topics:

• Develop the JAX-RS endpoint to delete entities
• Enhance the test setup for deterministic and repeatable integration tests
• Remove the deleted entity from the database

The source code for the Maven CRUD API application is available on GitHub.

For more quickstart tutorials on Jakarta EE, have a look at the overview page on my blog.

Have fun developing Jakarta EE CRUD API applications,

Phil

The post Jakarta EE 8 CRUD API Tutorial using Java 11 appeared first on rieckpil.

With the presence of Docker, Kubernetes and cheaper hardware, the deployment model of multiple applications inside one application server has passed. Now, you deploy one Jakarta EE application to one application server. This eliminates the need for different context paths.  You can use the root context / for your Jakarta EE application. With this blog post, you’ll learn how to achieve this for each Jakarta EE application server.

The default behavior for Jakarta EE application server

Without any further configuration, most of the Jakarta EE application servers deploy the application to a context path based on the filename of your .war. If you e.g. deploy your my-banking-app.war application, the server will use the context prefix /my-banking-app for your application. All you JAX-RS endpoints, Servlets, .jsp, .xhtml content is then available below this context, e.g /my-banking-app/resources/customers.

This was important in the past, where you deployed multiple applications to one application server. Without the context prefix, the application server wouldn’t be able to route the traffic to the correct application.

As of today, the deployment model changed with Docker, Kubernetes and cheaper infrastructure. You usually deploy one .war within one application server running as a Docker container. Given this deployment model, the context prefix is irrelevant. Mapping the application to the root context / is more convenient.

If you configure a reverse proxy or an Ingress controller (in the Kubernetes world), you are happy if you can just route to / instead of remembering the actual context path (error-prone).

Deploying to root context: Payara & Glassfish

As Payara is a fork of Glassfish, the configuration for both is quite similar. The most convenient way for Glassfish is to place a glassfish-web.xml file in the src/main/webapp/WEB-INF folder of your application:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN"
  "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
  <context-root>/</context-root>
</glassfish-web-app>

For Payara the filename is payara-web.xml:

<!DOCTYPE payara-web-app PUBLIC "-//Payara.fish//DTD Payara Server 4 Servlet 3.0//EN" "https://raw.githubusercontent.com/payara/Payara-Server-Documentation/master/schemas/payara-web-app_4.dtd">
<payara-web-app>
	<context-root>/</context-root>
</payara-web-app>

Both also support configuring the context path of the application within their admin console. IMHO this less convenient than the .xml file solution.

Deploying to root context: Open Liberty

Open Liberty also parses a proprietary web.xml file within src/main/webapp/WEB-INF: ibm-web-ext.xml

<web-ext
  xmlns="http://websphere.ibm.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
  version="1.0">
  <context-root uri="/"/>
</web-ext>

Furthermore, you can also configure the context of your application within your server.xml:

<server>
  <featureManager>
    <feature>servlet-4.0</feature>
  </featureManager>

  <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443"/>

  <webApplication location="app.war" contextRoot="/" name="app"/>
</server>

Deploying to root context: WildFly

WildFly also has two simple ways of configuring the root context for your application. First, you can place a jboss-web.xml within src/main/webapp/WEB-INF:

<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">
<jboss-web>
  <context-root>/</context-root>
</jboss-web>

Second, while copying your .war file to your Docker container, you can name it ROOT.war:

FROM jboss/wildfly
 ADD target/app.war /opt/jboss/wildfly/standalone/deployments/ROOT.war

For more tips & tricks for each application server, have a look at my cheat sheet.

Have fun deploying your Jakarta EE applications to the root context,

Phil

The post Deploy a Jakarta EE application to the root context appeared first on rieckpil.

I’ve been involved in Java EE since the very beginning, Having written one of the first ever books on Java EE. My involvement in Java EE / Jakarta EE has been on an education / advocacy role. Having written books, articles, blog posts and given talks in conferences about the technology. I advocate Jakarta EE not because I’m paid to do so, but because I really believe it is a great technology. I’m a firm believer that the fact that Jakarta EE is a standard, with multiple competing implementations, results in very high quality implementations, since Jakarta EE avoids vendor lock-in and encourages competition, benefiting developers.

Oracle’s donation of Java EE to the Eclipse Foundation was well received and celebrated by the Java EE community. Many prominent community members had been advocating for a more open process for Java EE, which is exactly what Jakarta EE, under the stewardship from the Eclipse Foundation provides.

There are some fundamental changes on how Jakarta EE is managed, that differ from Java EE, that benefit the Jakarta EE community greatly.

Fundamental differences between Java EE and Jakarta EE Management

Some of the differences in the way Jakarta EE is managed as opposed to Java EE are that there is no single vendor controlling the technology, there is free access to the TCK and there is no reference implementation.

No single company controls the standard

First and foremost, we no longer have a single company as a steward of Jakarta EE. Instead, we have several companies who have a vested interest in the success of the technology working together to develop the standard. This has the benefit that the technology is not subject to the whims of any one vendor, and, if any of the vendors loses interest in Jakarta EE, others can easily pick up the slack. The fact that there is no single vendor behind the technology makes Jakarta EE very resilient, it is here to stay.

TCK freely accessible

Something those of us involved heavily in Jakarta EE (and Java EE before), take for granted, but that may not be clear to others, is that Jakarta EE is a set of specifications with multiple implementations. Since the APIs are defined in a specification, they don’t change across Jakarta EE implementations, making Jakarta EE compliant code portable across implementations. For example, a Jakarta EE compliant application should run with minimal or no modifications on popular Jakarta EE implementations such as Apache Tomee, Payara, IBM’s OpenLiberty or Red Hat’s Thorntail

One major change that Jakarta EE has against Java EE is the fact that the Technology Compatibility Kit (TCK) is open source and free. The TCK is a set of test to verify that a Jakarta EE implementation is 100% compliant with all Jakarta EE specifications. With Java EE, organizations wanting to create a Java EE implementation, had to pay large sums of money to gain access to the TCK, once their implementation passed all the tests, their implementation was certified as Java EE compatible. The fact that the TCK was not freely accessible became a barrier to innovation, as smaller organizations and open source developers not always had the funds to get access to the TCK. Now that the TCK is freely accessible, the floodgates will open, and we should see a lot more quality implementations of Jakarta EE.

No reference implementation

Another major change between Java EE and Jakarta EE is that Java EE had the concept of a reference implementation. The idea behind having a Java EE reference implementation was to prove that suggested API specifications were actually feasible to implement. Having a reference implementation, however, had a side effect. If the reference implementation implemented something that wasn’t properly defined in the specification, then many developers expected all Java EE implementations to behave the same way, making the reference implementation a de-facto Java EE specification of sorts. Jakarta EE does away with the concept of a reference implementation, and will have multiple compatible implementations instead. The fact that there isn’t a reference implementation in Jakarta EE will result in more complete specifications, as differences in behavior between implementations will bring to light deficiencies in the specifications, these deficiencies can then be addressed by the community.

Conclusion

With multiple organizations with a vested interest in Jakarta EE’s success, a lowered barrier of entry for new Jakarta EE implementations, and better specifications Jakarta EE will become the de-facto standard in server-side Java development.

With the Eclipse Foundation Specification Process (EFSP) a single open source specification project has a dedicated project team of committers to create and maintain one or more specifications. The cycle of creation and maintenance extends across multiple versions of the specification, and so while individual members may come and go, the team remains and it is that team that is responsible for the every version of that specification that is created.

The first step in managing how intellectual property rights flow through a specification is to define the range of the work encompassed by the specification. Per the Eclipse Intellectual Property Policy, this range of work (referred to as the scope) needs to be well-defined and captured. Once defined, the scope is effectively locked down (changes to the scope are possible but rare, and must be carefully managed; the scope of a specification can be tweaked and changed, but doing so requires approval from the Jakarta EE Working Group’s Specification Committee).

Regarding scope, the EFSP states:

Among other things, the Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification. Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.

As a general rule, a scope statement should not be too precise. Rather, it should describe the intention of the specification in broad terms. Think of the scope statement as an executive summary or “elevator pitch”.

Elevator pitch: You have fifteen seconds before the elevator doors open on your floor; tell me about the problem your specification addresses.

The scope statement must answer the question: what does an implementation of this specification do? The scope statement must be aspirational rather than attempt to capture any particular state at any particular point-in-time. A scope statement must not focus on the work planned for any particular version of the specification, but rather, define the problem space that the specification is intended to address.

For example:

Jakarta Batch provides describes a means for executing and managing batch processes in Jakarta EE applications.

and:

Jakarta Message Service describes a means for Jakarta EE applications to create, send, and receive messages via loosely coupled, reliable asynchronous communication services.

For the scope statement, you can assume that the reader has a rudimentary understanding of the field. It’s reasonable, for example, to expect the reader to understand what “batch processing” means.

I should note that the two examples presented above are just examples of form. I’m pretty sure that they make sense, but defer to the project teams to work with their communities to sort out the final form.

The scope is “sticky” for the entire lifetime of the specification: it spans versions. The plan for any particular development cycle must describe work that is in scope; and at the checkpoint (progress and release) reviews, the project team must be prepared to demonstrate that the behavior described by the specifications (and tested by the corresponding TCK) cleanly falls within the scope (note that the development life cycle of specification project is described in Eclipse Foundation Specification Process Step-by-Step).

In addition the specification scope which is required by the Eclipse Intellectual Property Policy and EFSP, the specification project that owns and maintains the specification needs a project scope. The project scope is, I think, pretty straightforward: a particular specification project defines and maintains a specification.

For example:

The Jakarta Batch project defines and maintains the Jakarta Batch specification and related artifacts.

Like the specification scope, the project scope should be aspirational. In this regard, the specification project is responsible for the particular specification in perpetuity. Further the related artifacts, like APIs and TCKs can be in scope without actually being managed by the project right now.

Today, for example, most of the TCKs for the Jakarta EE specifications are rolled into the Jakarta EE TCK project. But, over time, this single monster TCK may be broken up and individual TCKs moved to corresponding specification projects. Or not. The point is that regardless of where the technical artifacts are currently maintained, they may one day be part of the specification project, so they are in scope.

I should back up a bit and say that our intention right now is to turn the “Eclipse Project for …” projects that we have managing artifacts related to various specifications into actual specification projects. As part of this effort, we’ll add Git repositories to these projects to provide a home for the specification documents (more on this later). A handful of these proto-specification projects currently include artifacts related to multiple specifications, so we’ll have to sort out what we’re going to do about those project scope statements.

We might consider, for example, changing the project scope of the Jakarta EE Stable APIs (note that I’m guessing a future new project name) to something simple like:

Jakarta EE Stable APIs provides a home for stable (legacy) Jakarta EE specifications and related artifacts which are no longer actively developed.

But, all that talk about specification projects aside, our initial focus needs to be on describing the scope of the specifications themselves. With that in mind, the EE4J PMC has created a project board with issues to track this work and we’re going to ask the project teams to start working with their communities to put these scope statements together. If you have thoughts regarding the scope statements for a particular specification, please weigh in.

Note that we’re in a bit of a weird state right now. As we engage in a parallel effort to rename the specifications (and corresponding specification projects), it’s not entirely clear what we should call things. You’ll notice that the issues that have been created all use the names that we guess we’re going to end up using (there’s more more information about that in Renaming Java EE Specifications for Jakarta EE).

It’s time to change the specification names…

When we first moved the APIs and TCKs for the Java EE specifications over to the Eclipse Foundation under the Jakarta EE banner, we kept the existing names for the specifications in place, and adopted placeholder names for the open source projects that hold their artifacts. As we prepare to engage in actual specification work (involving an actual specification document), it’s time to start thinking about changing the names of the specifications and the projects that contain their artifacts.

Why change? For starters, it’s just good form to leverage the Jakarta brand. But, more critically, many of the existing specification names use trademarked terms that make it either very challenging or impossible to use those names without violating trademark rules. Motivation for changing the names of the existing open source projects that we’ll turn into specification projects is, I think, a little easier: “Eclipse Project for …” is a terrible name. So, while the current names for our proto-specification projects have served us well to-date, it’s time to change them. To keep things simple, we recommend that we just use the name of the specification as the project name. 

With this in mind, we’ve come up with a naming pattern that we believe can serve as a good starting point for discussion. To start with, in order to keep things as simple as possible, we’ll have the project use the same name as the specification (unless there is a compelling reason to do otherwise).

The naming rules are relatively simple:

• Replace “Java” with “Jakarta” (e.g. “Java Message Service” becomes “Jakarta Message Service”);
• Add a space in cases where names are mashed together (e.g. “JavaMail” becomes “Jakarta Mail”);
• Add “Jakarta” when it is missing (e.g. “Expression Language” becomes “Jakarta Expression Language”); and
• Rework names to consistently start with “Jakarta” (“Enterprise JavaBeans” becomes “Jakarta Enterprise Beans”).

This presents us with an opportunity to add even more consistency to the various specification names. Some, for example, are more wordy or descriptive than others; some include the term “API” in the name, and others don’t; etc.

We’ll have to sort out what we’re going to do with the Eclipse Project for Stable Jakarta EE Specifications, which provides a home for a small handful of specifications which are not expected to change. I’ll personally be happy if we can at least drop the “Eclipse Project for” from the name (“Jakarta EE Stable”?). We’ll also have to sort out what we’re going to do about the Eclipse Mojarra and Eclipse Metro projects which hold the APIs for some specifications; we may end up having to create new specification projects as homes for development of the corresponding specification documents (regardless of how this ends up manifesting as a specification project, we’re still going to need specification names).

Based on all of the above, here is my suggested starting point for specification (and most project) names (I’ve applied the rules described above; and have suggested tweaks for consistency by strike out):

• Jakarta APIs for XML Messaging
• Jakarta Architecture for XML Binding
• Jakarta API for XML-based Web Services
• Jakarta Common Annotations
• Jakarta Enterprise Beans
• Jakarta Persistence API
• Jakarta Contexts and Dependency Injection
• Jakarta EE Platform
• Jakarta API for JSON Binding
• Jakarta Servlet
• Jakarta API for RESTful Web Services
• Jakarta Server Faces
• Jakarta API for JSON Processing
• Jakarta EE Security API
• Jakarta Bean Validation
• Jakarta Mail
• Jakarta Beans Activation Framework
• Jakarta Debugging Support for Other Languages
• Jakarta Server Pages Standard Tag Library
• Jakarta EE Platform Management
• Jakarta EE Platform Application Deployment
• Jakarta API for XML Registries
• Jakarta API for XML-based RPC
• Jakarta Enterprise Web Services
• Jakarta Authorization Contract for Containers
• Jakarta Web Services Metadata
• Jakarta Authentication Service Provider Interface for Containers
• Jakarta Concurrency Utlities
• Jakarta Server Pages
• Jakarta Connector Architecture
• Jakarta Dependency Injection
• Jakarta Expression Language
• Jakarta Message Service
• Jakarta Batch
• Jakarta API for WebSocket
• Jakarta Transaction API

We’re going to couple renaming with an effort to capture proper scope statements (I’ll cover this in my next post). The Eclipse EE4J PMC Lead, Ivar Grimstad, has blogged about this recently and has created a project board to track the specification and project renaming activity (as of this writing, it has only just been started, so watch that space). We’ll start reaching out to the “Eclipse Project for …”  teams shortly to start engaging this process. When we’ve collected all of the information (names and scopes), we’ll engage in a restructuring review per the Eclipse Development Process (EDP) and make it all happen (more on this later).

Your input is requested. I’ll monitor comments on this post, but it would be better to collect your thoughts in the issues listed on the project board (after we’ve taken the step to create them, of course), on the related issue, or on the EE4J PMC’s mailing list.