Jakarta Blogs

Adam Bien: AWS Infrastructure as Code: CloudFormation Origins, CDK Stacks, and Terraform Trade-offs--airhacks.fm podcast

Thu, 16 Apr 2026 13:13:56 +0000

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

The #393 airhacks.fm episode with Thorsten HoÌˆger (@hoegertn) about:

Migrating a German bank to AWS in 2012, the evolution from CloudFormation JSON to CDK, declarative state management, Terraform trade-offs, CDK stacks as atomic deployment units, regulated industries and compliance, and the CDK Book.

is available for download.

Ivar Grimstad: Hashtag Jakarta EE #328

Sun, 12 Apr 2026 09:59:00 +0000

Welcome to issue number three hundred and twenty-eight of Hashtag Jakarta EE!

In just about a week, Open Community eXperience is happening in Brussels, Belgium. The four days between April 21 and April 23 are packed with talks from amazing speakers delivering keynotes, regular talks, workshops, and BOFs. In addition to all the scheduled content, we have the hallway track. This is where it happens. Spontaneous conversations about all kinds of topics just appear out of nowhere. The hallway track is by far the most valuable aspect of attending conferences.

My talk titled The Past, Preseent, and Future of Enterprise Java – with Jakarta EE is scheduled for Wednesday. When I am not attending other talks or roaming the hallway, I can be found staffing the Eclipse Foundation booth in the exhibition area.

In the Jakarta EE Platform call this week, we discussed what that would be needed for Jakarta NoSQL to be included as one of the specifications in Jakarta EE 12. There is still some reluctance among some of our members to include this specification, so please make your voice heard if you want to see Jakarta NoSQL in Jakarta EE 12. If you have some extra time on your hand, you can also step in and help the project address the issues that the platform project has requested to strenghen its position as a candidate for inclusion.

Adam Bien: Green Java with Quarkus: Performance Benchmarks, SBOM, and Serverless Architecture--airhacks.fm podcast

Sat, 11 Apr 2026 12:52:50 +0000

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

The #392 airhacks.fm episode with Holly Cummins (@holly_cummins) about:

Quarkus energy efficiency benchmarks, greener Java, serverless SnapStart, JVM tuning, SBOM generation, and cheese fondue

is available for download.

Open Liberty: Jakarta EE 11 Platform, Java 26, and more in 26.0.0.4-beta

Tue, 07 Apr 2026 00:00:00 +0000

This beta introduces Jakarta EE 11 Platform and Web Profile, and delivers enhancements across Jakarta Authentication 3.1, Jakarta Authorization 3.0, and Jakarta Security 4.0. In addition, it provides a preview of Jakarta Data 1.1 M2, support for Java 26, MCP Server updates, and Jandex index improvements.

The Open Liberty 26.0.0.4-beta includes the following beta features (along with all GA features):

Jakarta EE 11 Platform and Web Profile

Open Liberty 24.0.0.11-beta was one of the ratifying implementations for Jakarta EE 11 Core Profile. Building on that foundation, the 26.0.0.4-beta release completes Jakarta EE 11 beta support, including Jakarta EE Application Client 11.0, Jakarta EE Web Profile 11.0, and Jakarta EE Platform 11.0.

Liberty provides convenience features that bundle all component specifications in the Jakarta EE Web Profile and Jakarta EE Platform. The webProfile-11.0 Liberty feature includes all Jakarta EE Web Profile functions, including the new Jakarta Data 1.0 component. The jakartaee-11.0 Liberty feature provides the Jakarta EE Platform version 11 implementation. For Jakarta EE 11 features in the application client, use the jakartaeeClient-11.0 Liberty feature.

These convenience features enable developers to rapidly develop applications using all APIs in the Web Profile and Platform specifications. Unlike the jakartaee-10.0 Liberty feature, the jakartaee-11.0 Liberty feature does not enable the Managed Beans specification function any longer, as this specification was removed from the platform which includes removal of the jakarta.annotation.ManagedBean annotation API. Applications relying on the @ManagedBean annotation must migrate to use CDI annotations.

The Jakarta EE 11 Platform specification removes all optional specifications from the platform, meaning Jakarta SOAP with Attachments, XML Binding, XML Web Services, and Enterprise Beans 2.x APIs functions are not included with the jakartaee-11.0 Liberty feature. To use these capabilities, explicitly add Liberty features to your server.xml feature list: xmlBinding-4.0 for XML Binding, xmlWS-4.0 for SOAP with Attachments and XML Web Services, and enterpriseBeansHome-4.0 for Jakarta Enterprise Beans 2.x APIs. Alternatively, use the equivalent versionless features with the jakartaee-11.0 platform.

When using the Liberty application client with the jakartaeeClient-11.0 feature, Jakarta SOAP with Attachments, XML Binding, and XML Web Services client functions are not available. To continue using these functions in your Liberty application client, enable the xmlBinding-4.0 and the new xmlWSClient-4.0 features in your client.xml file.

To enable the Jakarta EE 11 beta features in your Liberty server’s server.xml:

  <featureManager>
    <feature>jakartaee-11.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 11 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-11.0</feature>
  </featureManager>

You can enable the Jakarta EE 11 features on the Application Client Container in the client.xml:

 <featureManager>
       <feature>jakartaeeClient-11.0</feature>
 </featureManager>

For more information, see the Jakarta EE Platform 11 Specification and the Jakarta EE Web Profile 11 Specification.

Application Authentication 3.1 (Jakarta Authentication 3.1)

Jakarta Authentication defines a general SPI for authentication mechanisms, which are controllers that interact with a caller and the container’s environment to obtain and validate the caller’s credentials. It then passes an authenticated identity (such as name and groups) to the container.

The 3.1 version of the Jakarta Authentication API removes the deprecated Permission-related fields in the jakarta.security.auth.message.config.AuthConfigFactory class. The methods in the class no longer do permission checking also. These changes are part of Jakarta EE 11’s removal of SecurityManager support.

You can enable the Jakarta Authentication 3.1 feature by adding the appAuthentication-3.1 Liberty feature in the server.xml file:

    <featureManager>
        <feature>appAuthentication-3.1</feature>
    </featureManager>

For more information, see the Jakarta Authentication 3.1 specification and javadoc.

Application Authorization 3.0 (Jakarta Authorization 3.0)

Jakarta Authorization defines an SPI for authorization modules, which are repositories of permissions that facilitate subject-based security by determining whether a subject has a specific permission. It also defines algorithms that transform security constraints for specific containers, such as Jakarta Servlet or Jakarta Enterprise Beans, into these permissions.

The 3.0 API introduces the new jakarta.security.jacc.PolicyFactory and jakarta.security.jacc.Policy classes for doing authorization decisions. These classes are added to remove the dependency on the java.security.Policy class, which is deprecated in newer versions of Java. With the new PolicyFactory API, now you can have a Policy per policy context instead of having a global policy. This design allows separate policies to be maintained for each application.

Additionally, the 3.0 specification defines a mechanism to define PolicyConfigurationFactory and PolicyFactory classes in your application by using a web.xml file. This design allows for an application to have a different configuration than the server-scoped one, but still allow for it to delegate to a server scoped factory for any other applications. Authorization modules can do this delegation by using decorator constructors for both PolicyConfigurationFactory and PolicyFactory classes.

To configure your authorization modules in your application’s web.xml file, add specification defined context parameters:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_1.xsd"
  version="6.1">

  <context-param>
    <param-name>jakarta.security.jacc.PolicyConfigurationFactory.provider</param-name>
    <param-value>com.example.MyPolicyConfigurationFactory</param-value>
  </context-param>

  <context-param>
    <param-name>jakarta.security.jacc.PolicyFactory.provider</param-name>
    <param-value>com.example.MyPolicyFactory</param-value>
  </context-param>

</web-app>

Due to Jakarta Authorization 3.0 no longer using the java.security.Policy class and introducing a new configuration mechanism for authorization modules, the com.ibm.wsspi.security.authorization.jacc.ProviderService Liberty API is no longer available with the appAuthorization-3.0 feature. If a Liberty user feature configures authorization modules, the OSGi service that provided a ProviderService implementation must be updated to use the PolicyConfigurationFactory and PolicyFactory set methods. These methods configure the modules in the OSGi service. Alternatively you can use a Web Application Bundle (WAB) in your user feature to specify your security modules in a web.xml file.

Finally, the 3.0 API adds a new jakarta.security.jacc.PrincipalMapper class that you can obtain from the PolicyContext class when authorization processing is done in your Policy implementation. From this class, you can obtain the roles that are associated with a specific Subject to be able to determine whether the Subject is in the required role.

You can use the PrincipalMapper class in your Policy implementation’s impliesByRole (or implies) method, as shown in the following example:

    public boolean impliesByRole(Permission p, Subject subject) {
        Map<String, PermissionCollection> perRolePermissions =
            PolicyConfigurationFactory.get().getPolicyConfiguration(contextID).getPerRolePermissions();
        PrincipalMapper principalMapper = PolicyContext.get(PolicyContext.PRINCIPAL_MAPPER);

        // Check to see if the Permission is in the all authenticated users role (**)
        if (!principalMapper.isAnyAuthenticatedUserRoleMapped() && !subject.getPrincipals().isEmpty()) {
            PermissionCollection rolePermissions = perRolePermissions.get("**");
            if (rolePermissions != null && rolePermissions.implies(p)) {
                return true;
            }
        }

        // Check to see if the roles for the Subject provided imply the permission
        Set<String> mappedRoles = principalMapper.getMappedRoles(subject);
        for (String mappedRole : mappedRoles) {
            PermissionCollection rolePermissions = perRolePermissions.get(mappedRole);
            if (rolePermissions != null && rolePermissions.implies(p)) {
                return true;
            }
        }
        return false;
    }

You can enable the Jakarta Authorization 3.0 feature by adding the appAuthorization-3.0 Liberty feature in the server.xml file:

    <featureManager>
        <feature>appAuthorization-3.0</feature>
    </featureManager>

For more information, see the Jakarta Authorization 3.0 specification and javadoc.

Application Security 6.0 (Jakarta Security 4.0)

An In-memory Identity Store is a developer-defined store of credential information that is used during the Open Liberty authentication and authorization work flow. It provides a quick, simple, and convenient authentication mechanism for Liberty application testing, debugging, demos, and more.

Multiple HTTP Authentication Mechanisms (HAMs) can now be defined within the same application. These mechanisms can be specified through built-in Jakarta annotations such as @FormAuthenticationMechanismDefinition or through custom implementations of the HttpAuthenticationMechanism interface.
A new method is added to the SecurityContext interface called getAllDeclaredCallerRoles(), which returns a list of all static (declared) application roles that the authenticated caller is in.
References to the IdentityStorePermission class are removed as it was previously deprecated.

All features are available as part of appSecurity-6.0.

All feature use cases are targeted towards Jakarta EE web application developers who want to move to a modern Jakarta version and use implementations of the Jakarta Security 4.0 specification.

In-memory identity store

Before the introduction of the new identity store specification, Jakarta Security natively supported only two types of identity stores: database and LDAP, both of which are used for credential validation. While effective for production environments, these options were considered heavyweight for testing, debugging, and demonstration scenarios.

Developers can also implement custom identity stores, but doing so requires bespoke code to collect, validate, and manage credential information. This effort can divert attention from core application development. A built-in, in-memory identity store reduces this burden for non-production use cases such as testing, debugging, and demonstrations.

Multiple HAMs

It is now possible for multiple authentication mechanisms to logically act as a single HTTP Authentication Mechanism (HAM), providing a more flexible, dynamic, and configurable approach to the authentication workflow.

Access to the HttpAuthenticationMechanism is now abstracted by an internal implementation of the new Jakarta HttpAuthenticationMechanismHandler interface. This implementation prioritizes custom‑defined HAMs first and then falls back to the built‑in (annotation‑defined) HAMs, in the following order: OpenID, custom form, form, and basic authentication mechanisms.

Developers are free to provide their own implementation of the HttpAuthenticationMechanismHandler, allowing them to define a custom prioritization strategy for selecting HAMs. They must supply such an implementation if any built‑in HAMs are defined with the optional qualifiers attribute set.

getAllDeclaredCallerRoles()

The SecurityContext interface implementation is updated to include a new method, getAllDeclaredCallerRoles(), which returns a list of the declared application roles for an authenticated caller. If the caller is not authenticated or has no declared roles, the method returns an empty list.

How to use

Enable Jakarta Security 4.0 features within the server.xml file by adding the appSecurity-6.0 feature as shown in the following example:

<server description = "Liberty server">

    . . .

    <featureManager>
        <feature>appSecurity-6.0</feature>
    </featureManager>

    <webAppSecurity allowInMemoryIdentityStores="true"/>

    . . .

As shown in the preceding example, when an application defines an in‑memory identity store in code, its use must also be explicitly enabled in the server.xml configuration. By default, the allowInMemoryIdentityStores attribute is set to false, which instructs the Liberty authentication workflows not to use in‑memory identity stores, even when a custom identity store handler is present. For applications that rely on multiple HAMs, the allowInMemoryIdentityStores attribute does not need to be set.

In-Memory Identity Store

The Jakarta Security Specification 4.0 provides details on how to specify credential information to be used during the authentication workflow through the new @InMemoryIdentityStoreDefinition annotation, as shown in the following example:

. . .

@InMemoryIdentityStoreDefinition (
    priority = 10,
    priorityExpression = "${80/20}",
    useFor = {VALIDATE, PROVIDE_GROUPS},
    useForExpression = "#{'VALIDATE'}",
    value = {
        @Credentials(callerName = "jasmine", password = "secret1", groups = { "caller", "user" } )
    }
)

All attributes for the @InMemoryIdentityStoreDefinition annotation are shown in the example. The priority, priorityExpression, useFor, and useForExpression attributes are optional and set to sensible defaults.

The @Credentials annotation maps one or more caller names to a password and optional group values. The callerName and password attributes are mandatory. If either one is omitted, a compilation error occurs.

The example demonstrates a single caller definition with credential information that uses a plain-text password. However, it is highly recommended that passwords be supplied that uses an Open Liberty–supported encoding mechanism, as illustrated in the next example.

@InMemoryIdentityStoreDefinition (
    value = {
        @Credentials(callerName = "jasmine",  password = "{xor}LDo8LTorbg==", groups = { "caller", "user" } ),
        @Credentials(callerName = "frank", groups = { "user" }, password = "{hash}ARAAA <sequence shortened> Fyyw=="),
        @Credentials(callerName = "sally", groups = { "user" }, password = "{aes}ARAFIYJ <sequence shortened> WRQNA==")
    }
)

Encrypted and encoded passwords can be generated by using the Open Liberty securityUtility, which is included under the wlp/bin/securityUtility path. The following example demonstrates how to encode a text string by using the xor encoding mechanism.

wlp/bin/securityUtility encode --encoding=xor
Enter text: <enter text to encode>
Re-enter text:
{xor}PTA9Lyg

Multiple HAMs

Application Specification

The Jakarta Security 4.0 specification allows multiple HTTP Authentication Mechanisms (HAMs) to be defined within a single application, as shown in the following example:

@BasicAuthenticationMechanismDefinition(realmName="basicAuth")

@FormAuthenticationMechanismDefinition(
                loginToContinue = @LoginToContinue(errorPage = "/form-login-error.html",
                loginPage = "/form-login.html"))

@CustomFormAuthenticationMechanismDefinition(
                loginToContinue = @LoginToContinue(errorPage = "/custom-login-error.html",
                loginPage = "/custom-login.html"))

This example demonstrates how three HTTP Authentication Mechanisms (HAMs) can be defined within a single application.

Custom HAMs can also be defined in the same application by implementing the HttpAuthenticationMechanism interface in one or more classes, as shown in the following example:

@ApplicationScoped
// @Priority is optional and used to control selection priority if multiple custom definitions exist
@Priority(100)
public class CustomHAM implements HttpAuthenticationMechanism {

    @Override
    public AuthenticationStatus validateRequest(
        HttpServletRequest request,
        HttpServletResponse response,
        HttpMessageContext httpMessageContext) throws AuthenticationException {

            // implement custom logic here, and return an AuthenticationStatus
            return AuthenticationStatus.NOT_DONE;
    }
}

So a single application can have a mix of both annotation-defined HAMs and custom ones. In the previous two snippets of code, a total of four HAMs are defined (three by annotation and one custom one).

@Priority must be used to raise or lower the priority of one custom HAM over another. If not specified, then a default priority is assigned. If more than one custom HAM is defined, their priorities need to be explicitly set to unique values. If the priorities are set to the same value or remain unset and inherit the same default value, an error occurs.

HAM resolution

An internal implementation of the Jakarta Security 4.0 HttpAuthenticationMechanismHandler interface (the "internal HAM handler") is provided. When an application defines multiple HAMs, this internal handler selects a single HAM to be used in the authentication flow.

The order in which HAMs are considered (when present) is as follows:

Custom (developer‑provided) HAMs
- If multiple custom HAMs are defined, their relative order is resolved by using @Priority.
OpenIdAuthenticationMechanismDefinition
CustomFormAuthenticationMechanismDefinition
FormAuthenticationMechanismDefinition
BasicAuthenticationMechanismDefinition

Given this ordering, the Custom HAM is always selected in the authentication workflow if all five HAM types are defined in the application.

A developer must provide a custom implementation of the HttpAuthenticationMechanismHandler interface (a "custom HAM handler") if the internal HAM handler does not meet their requirements. A custom handler always takes precedence over the internal HAM handler, allowing any tailored algorithm to select a single HAM from multiple available mechanisms. Additional information about creating and using a custom HAM handler is provided in a later section.

Qualifiers

HAMs - whether defined through annotations or as custom defined - can also include an optional class‑level qualifier to simplify HAM injection into a custom HAM handler. For example, if you want to define qualified HAMs, you would first declare qualifier interfaces such as:

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

(Not shown is the qualifier definitions for User, Fallback which follow an identical pattern, and are used below).

Then, import and use the qualifiers in your in-built or custom HAM specifications, such as:

@CustomFormAuthenticationMechanismDefinition(<existing details not shown>, qualifiers={Admin.class})

@BasicAuthenticationMechanismDefinition(<existing details not shown>, qualifiers={User.class})

and

@ApplicationScoped
@Fallback   // add custom qualifier to be used during injection
public class CustomHAM implements HttpAuthenticationMechanism {

    @Override
    public AuthenticationStatus validateRequest (. . .)  {
         . . .
    }
}

The three HAMs defined in the example are available for injection into a custom HAM handler based on their qualifier names. This scenario represents the typical use case for applications that define multiple HAMs.

If qualifiers are specified in any of the built-in HAM definitions, a custom HAM handler must be provided; otherwise, an error is raised. This requirement comes directly from the Jakarta Security specification. Details about creating and using a custom HAM handler are explained in the next section.

To implement a custom HAM handler, define a public class that is annotated with @ApplicationScoped that implements the HttpAuthenticationMechanismHandler interface. Also, inject the qualified HAMs by using standard CDI syntax, as shown in the following section:

@Default
@ApplicationScoped
public class CustomHAMHandler implements HttpAuthenticationMechanismHandler {

    @Inject @Admin // this will be the FormHAM
    private HttpAuthenticationMechanism adminHAM;

    @Inject @User // this will be the BasicHAM
    private HttpAuthenticationMechanism userHAM;

    @Inject @Fallback // this will be the Custom HAM
    private HttpAuthenticationMechanism fallbackHAM;

    public AuthenticationStatus validateRequest(
        HttpServletRequest request,
        HttpServletResponse response,
        HttpMessageContext context
    ) throws AuthenticationException {

        String path = request.getRequestURI();

        // route to appropriate mechanism based on path, default to my-realm
        if (path.startsWith("/admin")) { // FormHAM
            return adminHAM.validateRequest(request, response, context);
        } else if (path.startsWith("/user")) { // BasicHAM
            return userHAM.validateRequest(request, response, context);
        } else { // Custom HAM
            return fallbackHAM.validateRequest(request, response, context);
    }
}

This custom HAM handler takes priority over the internal HAM handler, allowing a different prioritisation algorithm to be implemented.

getAllDeclaredCallerRoles()

To use the new SecurityContext method, inject the SecurityContext implementation into your application and call the method directly, as shown in the following section:

    @Inject
    private SecurityContext securityContext;

. . .

    Set<String> allDeclaredCallerRoles = securityContext.getAllDeclaredCallerRoles();

    System.out.println("All declared caller roles for caller ["
        + securityContext.getCallerPrincipal().getName()
        + "] are "
        + allDeclaredCallerRoles.toString());

Learn more

Further information can be found in the Jakarta Security Specification 4.0:

For more information about the securityUtility command, see the WAS Liberty base topic.

Beta support for Java 26

Java 26 is a recent Java release that introduces new features and enhancements over earlier versions that can be useful to review. This release is not a long-term support (LTS) release.

There are 10 new features (JEPs) in Java 26. Five are test features and five are fully delivered.

Test Features:

Delivered Features:

500: Prepare to Make Final Mean Final
504: Remove the Applet API
516: Ahead-of-Time Object Caching with Any GC
517: HTTP/3 for the HTTP Client API
522: G1 GC: Improve Throughput by Reducing Synchronization

A new change JEP 500 ("Prepare to Make Final Mean Final") in Java 26 starts enforcing true immutability of final fields by restricting their mutation when using deep reflection. In Java 26, such mutations still work but trigger runtime warnings by default, preparing developers for stricter enforcement. Future releases would likely throw exceptions instead, making the final truly nonmutable.

Developers can opt in early to this stricter behavior by using a JVM flag (for example, --illegal-final-field-mutation=deny) to detect issues sooner. This change improves program correctness, security, and JVM optimizations.

Take advantage of these changes now to gain more time to evaluate how your applications and microservices behave on Java 26.

Get started today by downloading the latest release of IBM Semeru Runtime 26 or Temurin 26, then download and install the Open Liberty 26.0.0.4-beta. Update your Liberty server’s server.env file with JAVA_HOME set to your Java 26 installation directory and start testing.

For more information on Java 26, see the Java 26 release notes page and API Javadoc page.

Updates to `mcpServer-1.0`

The Model Context Protocol (MCP) is an open standard that enables AI applications to access real-time information from external sources. The Liberty MCP Server feature mcpServer-1.0 allows developers to expose the business logic of their applications, allowing it to be integrated into agentic AI workflows.

This beta release of Open Liberty includes updates to the mcpServer-1.0 feature including dynamic registration of tools and support for version 2025-11-25 of the protocol.

Dynamically register MCP tools

Tools can now be registered dynamically through an API. This capability allows the set of available tools on the server to be adjusted based on configuration or environment.

Tools can be registered by injecting ToolManager and calling its methods to add, remove, and list the available tools on the server. The full Javadoc for ToolManager can be found within the Liberty beta in dev/api/ibm/javadoc/io.openliberty.mcp_1.0-javadoc.zip.

Tools can be registered when the application starts through the CDI Startup event. See the following example where the Startup event is used to register a weather forecast tool only if a WeatherClient bean is available.

    @Inject
    ToolManager toolManager;

    @Inject
    Instance<WeatherClient> weatherClientInstance;

    private void createWeatherTool(@Observes Startup startup) {
        if (weatherClientInstance.isResolvable()) {
            WeatherClient weatherClient = weatherClientInstance.get();
            toolManager.newTool("getForecast")
                       .setTitle("Weather Forecast Provider")
                       .setDescription("Get weather forecast for a location")
                       .addArgument("latitude", "Latitude of the location", true, Double.class)
                       .addArgument("longitude", "Longitude of the location", true, Double.class)
                       .setHandler(toolArguments -> {
                           Double latitude = (Double) toolArguments.args().get("latitude");
                           Double longitude = (Double) toolArguments.args().get("longitude");
                           String result = weatherClient.getForecast(
                                     latitude,
                                     longitude,
                                     4,
                                     "temperature_2m,snowfall,rain,precipitation,precipitation_probability");
                           return ToolResponse.success(result);
                       })
                       .register();
        }
    }

Tool registration starts with newTool(), then the information about the tool is added, including its title, description, and arguments. The handler supplies the code to run when the tool is called. It has one parameter, which is a ToolArguments object, which provides access to the arguments and other information about the tool call request. The handler must always create and return a ToolResponse.

Accept the 2025-11-25 MCP protocol

The mcpServer-1.0 feature now accepts version 2025-11-25 of the Model Context Protocol (MCP), although it does not support any new features introduced in this version of the protocol.

Supporting MCP 2025-11-25 introduces two notable behavior changes:

Tool name restrictions: Tool names are now limited to ASCII letters ('A–Z, a–z'), digits ('0–9'), and the underscore ('_'), hyphen ('-'), and dot ('.') characters.
Improved handling of invalid tool arguments: Invalid arguments passed when invoking a tool are now treated as tool execution errors rather than protocol errors. This change allows the LLM to receive feedback that the tool was called incorrectly and to retry with corrected arguments.

Paginated results

The result of a tools/list call is now paginated with a page size of 20. This means that if there are more than 20 tools deployed on the server, clients make several small calls to retrieve the list of tools, rather than one large call.

Bug fixes

During cancellation of a tool call, we check that both the session id and the authenticated user match the session id and the user that made the tool call. Previously only the session id was checked.
Messages that are returned to the MCP client no longer contain Open Liberty message codes.
Structured content is only returned when client is using protocol version 2025-06-18 or later.

Further information

For more information about the mcpServer-1.0 feature and how to get started using the beta, see our dedicated blog post.
For more information about the Model Context Protocol, see modelcontextprotocol.io

Preview of some Jakarta Data 1.1 M2 capability

Previews some new capability at the Jakarta Data 1.1 Milestone 2 level: Constraint subtype parameters for repository methods that constrain to repository @Find operations and limited use of Restriction with repository @Find operations. Also included from the prior beta are: retrieving a subset/projection of entity attributes and the @Is annotation.

Previously, parameter-based @Find reposotory methods could filter results only using equality conditions. This limitation has now been removed, allowing additional filtering options to be defined.

Filtering can now be specified in several ways. One approach is to define the repository method parameter as a Constraint subtype, or to indicate the constraint subtype by using the @Is annotation. Alternatively, a repository @Find method can include a special parameter of type Restriction, allowing the application to supply one or more restrictions dynamically at runtime when the method is invoked.

In Jakarta Data, you define simple Java objects called entities to represent data, and interfaces called repositories to define data operations. You inject a repository into your application and use it. The implementation of the repository is automatically provided.

Start by defining an entity class that corresponds to your data. With relational databases, the entity class corresponds to a database table and the entity properties (public methods and fields of the entity class) generally correspond to the columns of the table. An entity class can be:

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id and an entity property named version designates an automatically incremented version column.

Here’s a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public String name;

    public double price;

    public double weight;
}

After you define the entity to represent the data, it is usually helpful to have your IDE generate a static metamodel class for it. By convention, static metamodel classes begin with the underscore ('_') character, followed by the entity name.

Because this beta is available well before the release of Jakarta Data 1.1, IDE support for this generation cannot be expected yet. However, a static metamodel class can be provided in the same form that an IDE would generate for the Product entity.

@StaticMetamodel(Product.class)
public interface _Product {
    String ID = "id";
    String NAME = "name";
    String PRICE = "price";
    String WEIGHT = "weight";

    NumericAttribute<Product, Long> id = NumericAttribute.of(
            Product.class, ID, long.class);
    TextAttribute<Product> name = TextAttribute.of(
            Product.class, NAME);
    NumericAttribute<Product, Double> price = NumericAttribute.of(
            Product.class, PRICE, double.class);
    NumericAttribute<Product, Double> weight = NumericAttribute.of(
            Product.class, WEIGHT, double.class);
}

The first half of the static metamodel class includes constants for each of the entity attribute names so that you don’t need to otherwise hardcode string values into your application. The second half of the static metamodel class provides a special instance for each entity attribute, from which you can build restrictions and sorting to apply to queries at run time. This capability enables many powerful operations with repository queries, but those features are deferred to a future beta.

A repository defines operations that are related to the Product entity. Your repository interface can inherit from built-in interfaces such as BasicRepository and CrudRepository to gain various general-purpose repository methods for inserting, updating, deleting, and querying for entities. In addition to these capabilities, the repository can define custom operations by using the static metamodel and annotations such as @Find or @Delete.

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends CrudRepository<Product, Long> {

    // Filtering is pre-defined at development time by the @Is annotation,
    @Find
    @OrderBy(_Product.PRICE)
    @OrderBy(_Product.NAME)
    List<Product> costingUpTo(@By(_Product.PRICE) @Is(AtMost.class) double maxPrice);

    // Constraint types, such as Like, can also pre-define filtering.
    // Allow additional filtering at run time by including a Restriction,
    @Find
    Page<Product> named(@By(_Product.Name) Like namePattern,
                        Restriction<Product> filter,
                        Order<Product> sorting,
                        PageRequest pageRequest);

    // Retrieve a single entity attribute, identified by @Select,
    @Find
    @Select(_Product.PRICE)
    Optional<Double> priceOf(@By(_Product.ID) long productNum);

    // Retrieve multiple entity attributes as a Java record,
    @Find
    @Select(_Product.WEIGHT)
    @Select(_Product.NAME)
    Optional<WeightInfo> weightAndNameOf(@By(_Product.ID) long productNum);

    static record WeightInfo(double itemWeight, String itemName) {}
}

Here is an example of using the repository and static metamodel:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.insert(prod);

        // Filter by supplying values only:
        List<Product> found = products.costingUpTo(50.0, "%keyboard%");

        // Compute filtering at run time,
        Page<Product> page1 = products.named(
                        Like.suffix("printer"),
                        Restrict.all(_Product.price.times(taxRate).plus(shipping).lessThan(250.0),
                                     _Product.weight.times(kgToPounds).between(10.0, 20.0)),
                        Order.by(_Product.price.desc(),
                                 _Product.name.asc(),
                                 _Product.id.asc()),
                        PageRequest.ofSize(10));

        // Find one entity attribute:
        price = products.priceOf(prod.id).orElseThrow();

        // Find multiple entity attributes as a Java record:
        WeightInfo info = products.getWeightAndName(prod.id);
        System.out.println(info.itemName() + " weighs " + info.itemWeight() + " kg.");

        ...
    }
}

Learn more

Jakarta Data 1.1 API Javadoc
Jakarta Data 1.1 overview page

Maven coordinates for Data 1.1 Milestone 2:

<dependency>
    <groupId>jakarta.data</groupId>
    <artifactId>jakarta.data-api</artifactId>
    <version>1.1.0-M2</version>
</dependency>

This beta includes only the Data 1.1 features for entity subsets and projections, the @Is annotation, and Constraint subtypes as parameters for repository Find methods. It also includes limited support for Restriction as a special parameter for repository Find methods. The navigate operations are not implemented for restrictions and constraints. Other new Data 1.1 features are not included in this beta.

Support for Reading Jandex Indexes from WEB-INF/classes in Web Modules.

Previously, Jandex indexes across all module types were read only from META-INF/jandex.idx. This update extends support for web modules to also read indexes from WEB-INF/classes/META-INF/jandex.idx, bringing it in line with industry practices.

Jandex indexes are read from the original or the new location only when Jandex use is enabled. For compatibility with earlier versions, reading indexes from the new location must be enabled using a new application property.

Benefits

Improved Compatibility: Improve compatibility with industry standard practices.
Faster Startup Times: Continue to benefit from Jandex’s efficient annotation indexing.

Target Persona

Customers who wish to place Jandex indexes at industry standard locations in their web modules.

Target Features

This update applies to the scanning of classes within applications. Class scanning (which includes annotation scanning) is a general purpose function that is used by many features.

Problem Description

To gather information about application classes, including annotation data, the classes must be scanned. This scanning process is expensive because the entire application must be read and processed.

To improve performance, class scanning can be performed during application packaging, with the scan results stored in an index within the application. Jandex provides this capability.

Jandex scan results are typically written to META-INF/jandex.idx.

For JAR files, this path is relative to the root of the JAR. For WAR files, however, the META-INF/jandex.idx path can have two interpretations: it can be relative to the root of the WAR file, or relative to the WEB-INF/classes directory.

Before this update, Liberty used the location relative to the root of the WAR file. However, industry-standard practices place the location relative to the WEB-INF/classes directory. This update enables Liberty to also use the WEB-INF/classes location.

How to Use

Support for reading Jandex indexes under WEB-INF/classes is enabled by a new property on the application and applicationManager elements:

Property: useJandexUnderClasses
Description: Enables use of a Jandex index for WAR WEB-INF/classes under /WEB-INF/classes/META-INF/jandex.idx.
Possible values: true | false
Default value: false

Example: applicationManager

<applicationManager useJandex="true" useJandexUnderClasses="true"/>

Example: application

<application location="TestServlet40.ear" useJandex="true" useJandexUnderClasses="true"/>

When the new property is placed on an application manager element, it applies to all web modules of all applications. When the new property is placed on an application element, the property applies to only that application. If the property is set on both the application manager element and an application element, the value on the application element overrides the value on the application manager element for that application.

Limitation

Jandex index support requires explicit enablement. See the useJandex property on applicationManager and on application elements. The new useJandexUnderClasses property is meaningful only if the useJandex property is true.

For compatibility with earlier versions, reads of Jandex from the new location require explicit enablement. See the new useJandexUnderClasses property, as documented previously. Explicit enablement is required to prevent applications from accidentally reading an out of date Jandex index from the new location. An out of date Jandex index might cause application errors that are hard to detect.

The name of the new property, useJandexUnderClasses, is subject to revision.

Learn More

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. To enable the MCP server feature, follow the instructions from MCP standalone blog. The beta works with Java SE 25, Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.0</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>26.0.0.4-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[26.0.0.4-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Ivar Grimstad: Hashtag Jakarta EE #327

Sun, 05 Apr 2026 09:59:00 +0000

Welcome to issue number three hundred and twenty-seven of Hashtag Jakarta EE!

Happy Easter to everyone who celebrates! Right before the Easter holiday, I went to Amsterdam for Voxxed Days Amsterdam 2026. This was the second year this conference was organized, and they had almost 1000 registered attendees. Could this be the next Devoxx? It should certainly be a candidate. I wouldn’t be surprised if we see Devoxx Amsterdam next year.

I also attended the Jakarta EE Platform call, which was pretty good this week. Well attended and lots of good discussions. Among other things, we talked about how the three security specifications relate to each other. For historic reasons, Jakarta Authorization is not a part of Jakarta EE Web Profile, while both Jakarta Authentication and Jakarta Security are. There has been talk about merging the security specifications into one Jakarta Security at some point. The first step would be to include Authorization in Web Profile. This is certainly something we can do for Jakarta EE 12.

Since I am enjoying a couple of extra days at home over Easter (the first time I am home more than two consecutive days since January), I decided to do some cleaning up of the online resources for Javaforum Malmö. I have been in the fortunate situation of having Foo Café as a venue for the Java User Group over the last 10 years. I would provide the speaker and agenda, and Foo Café would handle everything else. Promotion, registration, catering, and sponsors. Our February event was one of the last at Foo Café before they closed down, so now I have to think differently. I created a simple website to gather our contact points and set up an Eventbrite account to use for registration to our events.

Open Liberty: UserRegistry Attribute Reader Enhancement, Jandex Index Format Support Update and more in 26.0.0.3

Tue, 24 Mar 2026 00:00:00 +0000

This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. Other highlights include changes to AES encoding and fixes for security vulnerabilities and bugs.

In Open Liberty 26.0.0.3:

View the list of fixed bugs in 26.0.0.3.

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 26.0.0.3

If you’re using Maven, include the following in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.0</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

UserRegistry Attribute Reader Enhancement

The UserRegistry API provides applications with the ability to retrieve specific user attributes and search for users based on attribute values directly from LDAP and custom user registries.

What’s New?

Previously, the UserRegistry API supported only basic user lookups such as searching by userSecurityName or by using wildcard pattern matching. However, it did not allow applications to retrieve specific user attributes or search for users based on attribute values. These capabilities were available in traditional WebSphere through the VMM API. The introduction of these two new APIs now enables applications to search for users and retrieve attributes from LDAP and custom user registries.

With this enhancement, you can now retrieve specific attributes for a user by using the getAttributesForUser() method. This method supports retrieval of individual attributes such as email or phoneNumber, or "*" to retrieve all available attributes for a user.

You can also search for users based on attribute values by using the getUsersByAttribute() method, enabling applications to locate users by matching specific attribute criteria. These methods are supported for LDAP user registries. Custom user registry implementations can also implement and support these methods.

How to Use It

New API methods added to UserRegistry.java:

default Map<String, Object> getAttributesForUser(String userSecurityName, Set<String> attributeNames)

Description: Returns a Map<String, Object> containing the specified attributesNames and their corresponding values for the given userSecurityName, as configured in the LDAP user registry.

UserRegistry ur = RegistryHelper.getUserRegistry("realmName");

// valid ldap attribute names
Set<String> attributeNames = Set.of("telephoneNumber", "uid", "mail");  // or "*" for retrieving all attributes
Map<String, Object> result = ur.getAttributesForUser("testuser", attributeNames);

// output in trace.log
> getAttributesForUser Entry
  testuser
  [telephoneNumber, uid, mail]

< getAttributesForUser Exit
  {uid=testuser, mail=testuser@example.com, telephoneNumber=<telephone-number>}

default SearchResult getUsersByAttribute(String attributeName, String value, int limit)

Description: Returns a SearchResult object that contains a list of users that match an attributeName with specified value that is configured in the LDAP user registry.

UserRegistry ur = RegistryHelper.getUserRegistry("realmName");

SearchResult searchResult = ur.getUsersByAttribute("email", "testuser@example.com", 1);

// output in trace.log
> getUsersByAttribute Entry
  email
  testuser@example.com
  1

< getUsersByAttribute Exit
  SearchResult hasMore=false [testuser]

To learn more about the user registry, see the following resources:

Jandex Index Format Support Update

Open Liberty now supports the latest Jandex index formats, allowing the use of Jandex indexes that are created with Jandex version 3.1.0 and later. Jandex is a space‑efficient Java annotation indexer and offline reflection library that improves application startup performance by pre‑indexing class metadata.

This feature targets application developers and DevOps engineers who work with Jakarta EE and MicroProfile applications. It is designed to optimize application startup times and reduce runtime costs.

What’s New?

With this update, Open Liberty supports Jandex index formats 11, 12, and 13. Jandex versions 3.1.0 through the current latest version, 3.5.3, generate indexes that use these formats.

Previously, Open Liberty supported Jandex index format versions only up to and including version 10. This index format limitation meant that applications packaged with Jandex indexes could not use index formats beyond version 10 while retaining the expected performance improvements. To preserve these performance benefits, build tooling had to continue using a Jandex version prior to 3.1.0, or explicitly configure Jandex index generation to produce indexes that use index format up to and including version 10.

Benefits

The added support for Jandex index formats has several benefits:

Improved Compatibility: Works seamlessly with the latest versions of build tools and frameworks that use newer Jandex versions
Faster Startup Times: Continue to benefit from Jandex’s efficient annotation indexing without version constraints
Reduced Maintenance: No need to maintain multiple Jandex versions or regenerate indexes for compatibility
Future-Proof: Stay current with the Jandex ecosystem as it evolves

Limitations

When using Jandex indexes, ensure that the index files are kept up to date with the application classes. If a Jandex index is not synchronized with the application classes, it can contain incorrect annotation data, which can cause the application to function incorrectly. Out‑of‑date Jandex indexes cannot be reliably detected.

Open Liberty does not read index formats higher than index format 13. If a new version of Jandex adds a higher index format version, Open Liberty requires an update before it can read Jandex indexes that use the higher index format version.

The Open Liberty feature mpGraphQL, which is obtained from an external source, is limited to reading Jandex index formats no higher than index format 10. If the feature mpGraphQL is used, Jandex indexes should be generated by using index format 10. This limitation applies to all current versions of mpGraphQL, including the current highest version, mpGraphQL-2.0.

Lifting Restriction

Previously, when Jandex usage was enabled and an application included Jandex indexes that used formats 11 through 13, Open Liberty displayed an error message and ignored those indexes. In such cases, annotation scanning was performed by using Liberty’s internal annotation scanning mechanism.

With the addition of support for Jandex index formats 11 through 13, Open Liberty now uses indexes that are generated in these formats. These indexes must be kept up to date with the application classes. Ensure that the Jandex indexes packaged with your application accurately reflect the current application classes.

How to Use

No configuration changes are required in the server.xml file to enable support for the new Jandex index formats. Open Liberty automatically detects the Jandex index format and selects the appropriate index reader for that format. It reads indexes that use formats 11, 12, and 13, and continues to support indexes that use format up to version 10.

By default, Jandex usage is disabled. To enable Jandex, set the useJandex property to true in either an application element or the applicationManager element.

If you are generating Jandex indexes as part of your build process, you can now use the latest Jandex Maven plugin or Gradle plugin versions:

Maven Example:

<plugin>
    <groupId>io.smallrye</groupId>
    <artifactId>jandex-maven-plugin</artifactId>
    <version>3.5.3</version>
    <executions>
        <execution>
            <id>make-index</id>
            <goals>
                <goal>jandex</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Gradle Example:

plugins {
    id 'org.kordamp.gradle.jandex' version '2.3.0'
}

Open Liberty automatically detects and recognizes the generated META-INF/jandex.idx file for any supported index format version.

For more information, see the Jandex Documentation

AES encoding changes

The securityUtility encode command now requires a key to be specified for AES encodings. Specify a key by including one of the following options: --key, --base64Key, --aesConfigFile, or --keyring. This update resolves CVE-2025-14923.

The following command now results in an error because a key is not specified in the command.

securityUtility encode --encoding=aes "password"

When using AES encoding, one of the following arguments must be specified: --key, --base64Key, --aesConfigFile, or --keyring.

The following is an example of a valid usage with the new requirement.

securityUtility encode --encoding=aes --key=mycustomkey "password"
{aes}ARArmkfkgGyE1eiN8mKKjnkUDrFUFuuq2FlpDqrJKBgTAEYeN+PLP45wChLvIhlnWEDHnSA4zJI9KA3k5R9e/QDC+O2tzr3EwD3IMMAfvfOYxxqNPmoXqIeRVPD8TPZWnIIPmCnvyROw5A8=

For more information, see the full documentation for securityUtility encode and password encryption.

Security vulnerability (CVE) fixes in this release

CVE	CVSS Score	Vulnerability Assessment	Versions Affected	Notes
CVE-2025-14923	4.7	Weaker security	17.0.0.3-26.0.0.2
CVE-2024-29371	7.5	Denial of service	21.0.0.3-26.0.0.2	Affects the `openidConnectClient-1.0`, `socialLogin-1.0`, `mpJwt-1.2`, `mpJwt-2.0`, `mpJwt-2.1`, and `jwt-1.0` features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 26.0.0.3.

Get Open Liberty 26.0.0.3 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

The OmniFish Team: Eclipse GlassFish: This Isn’t Your Father’s GlassFish

Wed, 04 Mar 2026 17:04:42 +0000

For years, developers and organizations have held certain beliefs about GlassFish, often based on their experiences with older versions. If you still think of GlassFish as a slow, unsupported, and purely for-development application server, it’s time to take a fresh look. At OmniFish, we’ve been working hard to change that perception since 2022. The Eclipse GlassFish of today, particularly from version 7.0 onwards, is a completely different platform, and we’re proud to show you what we’ve helped to build with the rest of the Eclipse GlassFish contributors.

This article explores the key differences between the modern Eclipse GlassFish and its predecessor, Oracle GlassFish and older Eclipse GlassFish versions. We’ll show you how GlassFish has evolved into a robust, enterprise-grade platform with commercial support from our team at OmniFish, with frequent updates, and a strong commitment to modern Java standards and modern lightweight deployments. In short, this is no longer your father’s GlassFish.

Article Contents

[â€¦]

The OmniFish Team: GlassFish 8 Released: Enterprise-Grade Java, Redefined. What’s new?

Thu, 12 Feb 2026 10:07:48 +0000

The next generation of enterprise Java is here. The final version of Eclipse GlassFish 8 landed on 5 February 2026. It’s a big milestone and reinforces GlassFish as a top-tier, enterprise-grade platform for mission-critical systems. Backed by the commercial support and expertise of OmniFish, GlassFish 8 is not just an open-source project; it is a robust, production-ready solution designed for organizations that demand reliability, performance, and innovation.

The final version of Eclipse GlassFish 8.0.0:

Is Jakarta EE 11 Platform compatible*
Requires at least Java 21, tested on Java 21 and 25
Quality assured by OmniFish using a comprehensive test suite

* GlassFish 8.0.0 passed the Jakarta EE 11 TCK and the compatibility request will be raised as soon as the summary for all the tests suites is assembled together. The previous milestone release of GlassFish 8, released in December 2025, is already certified.

This release represents a significant leap forward, with support for the whole Jakarta EE 11 platform, the latest major version of Jakarta EE. GlassFish 8 builds upon the solid foundation of GlassFish 7.1 and introduces a host of new features that empower developers to build scalable, secure, and high-performance applications with ease. GlassFish continues to be at the forefront of the Jakarta EE ecosystem, with frequent updates and a strong commitment to modern Java standards.

Building on a Solid

[…]

Christopher Guindon: Scaling the Open VSX Registry responsibly with rate limiting

Wed, 11 Feb 2026 20:05:00 +0000

The Open VSX Registry has become widely used infrastructure for modern developer tools. That growth reflects strong trust from the ecosystem, and it brings a shared responsibility to keep the Registry reliable, predictable, and equitable for everyone who depends on it.

In a previous post, I shared an update on strengthening supply-chain security in the Open VSX Registry, including the introduction of pre-publish checks for extensions. This post focuses on the operational side of the same goal: ensuring the Registry remains resilient and sustainable as usage continues to grow.

The Open VSX Registry is free to use, but not free to operate

Operating a global extension registry requires sustained investment in:

Compute and storage to serve and index extensions at scale
Bandwidth to deliver downloads and metadata worldwide
Security to protect users, publishers, and the service itself
Staff to operate, monitor, secure, and support the Registry

These costs scale directly with usage.

AI-driven usage is scaling faster than ever

Demand on the Open VSX Registry is increasing rapidly, and AI-enabled development is accelerating that trend. A single developer can now orchestrate dozens of agents and automated workflows, generating traffic that previously would have required entire teams. In practical terms, that can mean the equivalent load of twenty or more traditional users, with direct impact on compute, bandwidth, storage, security capacity, and operational oversight.

This is not unique to the Open VSX Registry. It is an industry-wide challenge. Stewards of public package registries such as Maven Central, PyPI, crates.io, and Packagist have recently raised the same sustainability concerns in a joint statement on sustainable stewardship. Mike Milinkovich, Executive Director of the Eclipse Foundation, echoed that message in his post on aligning responsibility with usage.

As reliance on shared open infrastructure grows, sustaining it becomes a collective responsibility across the ecosystem.

Open VSX is critical, and often invisible, infrastructure

Many developers and organisations may not realise how often they rely on the Open VSX Registry. It provides the extension infrastructure behind a growing number of modern developer platforms and tools, including Amazon’s Kiro, Cursor, Google Antigravity, Windsurf, VSCodium, IBM’s Project Bob, Trae, Ona (formerly Gitpod), and others.

If you use one of these tools, you use the Open VSX Registry.

The Open VSX Registry remains a neutral, vendor-independent public service, operated in the open and governed by the Eclipse Foundation for the benefit of the entire ecosystem.

For developers, the expectation is simple: Open VSX should remain fast, stable, secure, and dependable as the ecosystem grows.

As more platforms and automated systems rely on the Registry, continuous machine-driven traffic can place sustained load on shared infrastructure. Without clear operational guardrails, that can affect performance and availability for everyone.

A practical step for sustainable and reliable operations

Usage has shifted from primarily human-driven access to continuous automation driven by CI systems, cloud-based tooling, and AI-enabled workflows. That shift requires operational controls that scale predictably.

Rate limiting provides a structured way to manage high-volume automated traffic while preserving the performance developers expect. It also ensures that operational decisions are based on real usage patterns and that expectations for large-scale consumption are clear and transparent.

Rate limits aren’t entirely new. Like most public infrastructure services, the Open VSX Registry has long had baseline protections in place to prevent sustained high-volume usage from degrading performance for everyone. What’s changing now is that we’re moving from a one-size-fits-all approach to defined tiers that more accurately reflect different usage patterns. This allows us to keep the Registry stable and responsive for developers and open source projects, while providing a clear, supported path for sustained at-scale consumption.

For individual developers and open source projects, day-to-day workflows remain unchanged. Publishing extensions, searching the registry, and installing tools will continue to work as they always have for typical usage.

A measured, transparent rollout

Rate limiting will be introduced incrementally, with an emphasis on platform health and operational stability.

The initial phase focuses on visibility and observation before any limits are adjusted. This includes improved insight into traffic patterns for registered consumers, baseline protections for anonymous high-volume usage, and a monitoring period before any limits are adjusted.

This work is being done in the open so the community can follow what is changing and why. Progress and discussion are tracked publicly in the Open VSX deployment issue:
https://github.com/EclipseFdn/open-vsx.org/issues/5970

What this means for the community

The goal is to keep the Open VSX Registry reliable and fair as it scales, while minimizing impact on normal use.

For most users, nothing should feel different. Developers should see little to no impact, and publishers should not experience disruption to normal publishing workflows. Sustained, high-volume automated consumers may need to coordinate with the Registry to ensure their usage can be supported reliably over time.

Organisations that depend on the Open VSX Registry for sustained or commercial-scale usage are encouraged to get in touch. Coordinating early helps us plan capacity, maintain reliability, and support the broader ecosystem. Please contact the Open VSX Registry team at infrastructure@eclipse-foundation.org.

The intent is not restriction, but clarity in support of fairness, stability, and long-term sustainability.

Looking ahead

Automation is reshaping how developer infrastructure is consumed. Responsible rate limiting is one step toward ensuring the Open VSX Registry can continue to serve the ecosystem reliably as those patterns evolve.

We will continue to adapt based on real-world usage and community input, with the goal of keeping the Open VSX Registry a dependable shared resource for the long term.

Christopher Guindon: We’re hiring: improving the services that support a global open source community

Thu, 05 Feb 2026 19:02:00 +0000

The Eclipse Foundation supports a global open source community by providing trusted platforms, services, and governance. As a vendor-neutral organisation, we operate infrastructure that enables collaboration across projects, organisations, and industries.

This infrastructure supports project governance, developer tooling, and day-to-day operations across Eclipse open source projects. While much of it runs quietly in the background, it plays a critical role in the health, security, and sustainability of those projects.

We are expanding the Software Development team with two new roles. Both positions involve contributing to the design, development, and operation of services that are widely used, security-sensitive, and expected to operate reliably at scale.

Software engineer: security and detection

One of the roles is a Software Engineer position with a focus on security and detection engineering, alongside general development and operations.

This role will work on Open VSX Registry, an open source registry for VS Code extensions operated by the Eclipse Foundation. As adoption grows, maintaining the integrity and trustworthiness of the registry requires continuous analysis, detection, and operational safeguards.

In this role, you will:

Analyse suspicious or malicious extensions and related artefacts
Develop, test, and maintain YARA rules to detect malicious or policy-violating content
Design, implement and contribute improvements to backend services, including new features, abuse prevention, rate-limiting, and operational safeguards

This is hands-on work that combines backend development with practical security analysis. The outcome directly improves the reliability, integrity, and operation of services that are part of the developer tooling supply chain.

For more context on this work, see my recent post on strengthening supply-chain security in Open VSX.

To apply:
https://eclipsefoundation.applytojob.com/apply/eXFgacP5SJ/Software-Engineer

Software developer: open source project tooling and services

The second role is a Software Developer position focused on improving the tools and services that support Eclipse open source projects.

This work centres on maintaining and evolving systems that our open source projects and contributors rely on every day. It includes:

Maintaining and modernising project-facing applications such as projects.eclipse.org, built with Drupal and PHP
Developing Python tooling to automate internal processes and improve project metrics
Improving services written in Java or JavaScript that support project governance workflows

As with the Software Engineer role, this position involves contributing to production services. The focus is on incremental improvement, reducing technical debt, and ensuring systems remain maintainable, secure, and reliable as they evolve.

To apply:
https://eclipsefoundation.applytojob.com/apply/mvaSS7T8Ox/Software-Developer

What we are looking for

Across both roles, we are looking for people who:

Take a pragmatic approach to problem solving
Are comfortable working in a remote, open source environment
Value clear documentation and thoughtful communication
Enjoy understanding how systems work and how to improve them over time

If you are interested in working on open source infrastructure with real users and real impact, we would be happy to hear from you.

Jan Supol: Jersey 3.1.0 behaviour changes

Wed, 21 Jan 2026 15:20:34 +0000

This article discusses backward-incompatible changes in Jersey 3.1.0. While Jersey tries to minimize these incompatible changes, the changes are forced by the Platform Specification Project, API project, security reasons, or by an unstoppable evolution. Jersey 3.1.0 drops compatibility with JDK … Continue reading →

Alexius Diakogiannis: The Ultimate 10 Years Java Garbage Collection Guide (2016–2026) – Choosing the Right GC for Every Workload

Fri, 16 Jan 2026 16:19:56 +0000

First published on foojay.io

Memory management remains the primary factor for application performance in enterprise Java environments. Between 2017 and 2025, the ecosystem shifted from manual tuning to architectural selection. Industry data suggests that 60 percent of Java performance issues and 45 percent of production incidents in distributed systems stem from suboptimal Garbage Collection (GC) behavior. This guide provides a strategic framework for selecting collectors based on workload characteristics. It covers the transition from legacy collectors to Generational ZGC, analyzing trade-offs regarding throughput, latency, and hardware constraints with mathematical precision.

Introduction

The era of “write once, run anywhere” has evolved. In modern cloud-native architectures, you must “tune everywhere.” The migration from bare-metal monoliths to containerized microservices fundamentally changed how the Java Virtual Machine (JVM) interacts with memory.

A collector that performs well for a batch process often fails in a low-latency trading API. Selecting the wrong collector is no longer a minor configuration error. It is an architectural flaw. This flaw leads to cascading latency in microservices, instability in database connections, and wasted cloud resources.

This guide analyzes five primary workload categories. It synthesizes performance data from JDK 8 through JDK 25. It provides a technical decision matrix for Senior Architects and Site Reliability Engineers (SREs).

Workload Analysis and Strategic Selection

We categorize applications based on their resource patterns and business goals. Each category requires a distinct memory management strategy supported by specific mathematical tuning models.

Microservices (Spring Boot/Quarkus)

The Challenge: You must balance Resident Set Size (RSS) efficiency against startup time.
In Kubernetes environments, engineers often restrict pods to fewer than 2 processors and 2 GB of RAM. The JVM ergonomics often default to the Serial GC in these conditions. This happens even if you specify another collector.

The Strategy:
For most microservices, G1 GC is the balanced choice. However, deployment density matters. Research shows that G1 is the most memory-efficient collector for dense environments. In JDK 20 and later, engineers removed one of the marking bitmaps from G1. This reduced its native memory footprint, making it highly suitable for small containers.

Warning on ZGC in Microservices:
Do not blindly apply ZGC to small containers. ZGC requires significant headroom. It typically needs 25 to 35 percent free memory to function without stalling. In an 8 GB container, ZGC images are significantly larger than G1 images. Tests show that ZGC struggles to manage trees of 10 services in constrained RAM. It often fails with Out-Of-Memory (OOM) errors where G1 remains stable.

Legacy JEE (WebLogic/JBoss/Payara)

The Challenge: These systems handle large session states and accumulate legacy memory leaks.
Older applications relied on Concurrent Mark Sweep (CMS). CMS was designed for shorter pauses but required shared processor resources. It was deprecated in JDK 9 and removed in JDK 14.

The Strategy:
G1 GC is the primary successor for these workloads. It handles large heaps up to 128 GB by using region-based incremental collection.
Operators must monitor heap usage after full cycles. If heap usage consistently stays above 85 percent, the application likely has a memory leak. This indicates a code issue rather than a tuning issue.

Stateful UI (Vaadin/JSF)

The Challenge: These frameworks generate numerous medium-lived objects.
User sessions reside in the heap for minutes or hours. This behavior contradicts the “weak generational hypothesis” that most objects die young. Standard configurations often promote these session objects to the Old Generation too quickly. This leads to expensive full-heap collections.

The Strategy:
Tuning the SurvivorRatio is critical here. A standard ratio is 8 to 1. Changing this to 6 to 1 allows objects to stay in the Young Generation longer. Empirical testing shows this reduces premature promotions by 25 to 30 percent. Generational ZGC is also an optimal choice here. It manages mixed collections across generations effectively.

Data Intensive (Spark/Flink/Batch)

The Challenge: The priority is raw throughput.
Batch workloads must complete processing windows quickly. Individual pause times do not matter. A 5-second pause is acceptable if the job finishes 10 minutes earlier.

The Strategy:
Parallel GC (the “throughput collector”) remains the champion. It utilizes all available cores for collection, achieving 95 to 98 percent processing efficiency. However, it requires careful thread configuration on large multi-core servers to prevent OS context-switching overhead.

Mathematical Tuning Model: GC Threads
To optimize Parallel GC, explicitly set the thread count (Threads_GC) based on your available CPU cores (N_cpu).

This formula ensures the GC utilizes resources efficiently without overwhelming the operating system scheduler on massive batch servers.

Ultra-Low Latency

The Challenge: High-frequency APIs require sub-millisecond pauses.
Trading systems cannot tolerate the unpredictable pauses of G1 or Parallel GC. However, low-latency collectors like ZGC race against the application’s object creation. If the application creates objects faster than the collector can clean them, you hit an “Allocation Stall.”

The Strategy:
ZGC maintains pause times under 1 millisecond for heaps ranging from 8 GB to 16 TB using colored pointers and load barriers. To ensure stability, you must monitor the Allocation Rate.

Mathematical Tuning Model: Allocation Rate
You must calculate the Allocation Rate (R_alloc) over a time period (t) to determine if your heap headroom is sufficient.

If R_alloc consistently approaches the concurrent collection speed of ZGC, you must either increase the heap size or optimize the code. For modern stacks on JDK 21 or later, Generational ZGC is the superior choice as it handles high allocation rates by frequently clearing the Young Generation, preventing stalls.

Technical Performance Deep Dives

This section explores the specific trade-offs involved in migration and architecture design.

Migration Trade-offs: ParallelOld to ZGC

Migrating from ParallelOld to ZGC is a trade-off between raw speed and predictability.

You trade approximately 7 to 15 percent of raw throughput for a 1000x improvement in pause predictability.

ZGC imposes a “tax” on the system.

CPU Overhead: ZGC adds an 8 to 20 percent CPU overhead. This comes from the concurrent threads that run alongside your application.
Cache Efficiency: The use of colored pointers and read barriers impacts the processor cache. L3 cache hit rates often decline by 10 to 15 percent due to pointer metadata operations.
NUMA Penalty: In Non-Uniform Memory Access (NUMA) architectures, ZGC relocation threads can suffer a 20 to 30 percent performance penalty. You must pin these threads to local memory domains to avoid this.

Microservices and Cumulative Latency

In a microservice architecture, latency accumulates. A single user request often triggers a chain of calls across 5 to 10 services. This creates a “fan-out” effect.

If each service uses a collector like G1 or Parallel, the pauses add up. Cumulative GC pauses across a chain can amplify total latency by 3 to 5 times compared to a monolith.

Using ZGC or Shenandoah dramatically mitigates this. Tests indicate that migrating to low-latency collectors reduces this cascading latency effect by 65 percent. However, this introduces resource contention. The collector competes with application threads for CPU cycles and memory bandwidth.

Database Connectivity Stability

Database connections are heavy, long-lived objects. They test the stability of a collector.

Empirical testing indicates that CMS was historically the most stable collector for database-intensive microservices. It handled the highest number of managed instances before crashing.

Early versions of ZGC (Non-Generational) struggled here. In small container tests with DB connections, non-generational ZGC frequently threw NullPointerException errors. It failed to maintain connectivity due to allocation stalls.

Generational ZGC (JDK 21+) resolves these issues. It frequently collects the young generation where session-related objects reside. This protects the long-lived database connections.

Benchmark: In Apache Cassandra tests, non-generational ZGC failed at 75 concurrent clients. Generational ZGC maintained stability with up to 275 concurrent clients.

Technical Matrix and Decision Logic

Use this data to guide your architectural decisions.

Collector Comparison (JDK 8–25)

Collector	Supported JDK	Ideal Heap Size	Pause Time Target	CPU Overhead	Key Technology
Serial	8–25	< 100 MB	N/A (Long STW)	Lowest	Single-threaded STW
Parallel	8–25	Any	Acceptable STW	Low	Multi-threaded STW
G1	9–25 (Default)	6 GB – 128 GB	< 200ms	Medium	Region-based evacuation
ZGC	11–25	8 GB – 16 TB	< 1ms	High (8-20%)	Colored pointers
Shenandoah	12–25	2 GB – 10 TB	< 10ms	High	Concurrent compaction

The Decision Tree

Follow this logic to select the correct collector.

Scenario A: The Resource Constraint

Is the environment a tiny container (< 2 cores/2GB RAM) or is the heap < 100 MB?

Selection: Use Serial GC (-XX:+UseSerialGC).

Scenario B: The Batch Processor

Is the priority 4–8 hour batch processing windows where total throughput is the only metric?

Selection: Use Parallel GC (-XX:+UseParallelGC).

Scenario C: The Generalist

Is the application a general web service with balanced latency and throughput needs? Is the heap-to-container ratio > 80%?

Selection: Use G1 GC (-XX:+UseG1GC).

Scenario D: The High-Performance Specialist

Does the application require sub-1ms response times on large heaps (> 32 GB) on JDK 21+? Do you have 25% memory headroom?

Selection: Use Generational ZGC (-XX:+UseZGC -XX:+ZGenerational).

Scenario E: The Alternative

Are you on a non-Oracle OpenJDK and require low latency without ZGC multi-mapping?

Selection: Use Shenandoah GC (-XX:+UseShenandoahGC).

G1 vs Generational ZGC in 2026

For years, the standard advice was “G1 is always best.” The arrival of Generational ZGC in JDK 21 through JDK 25 challenges this.

The legacy non-generational ZGC suffered from allocation stalls. It had to scan the entire heap to find garbage. This works poorly when an application creates objects faster than the collector can clean them.

Generational ZGC exploits the Weak Generational Hypothesis, most objects die young.

By splitting the heap into generations, it achieves two goals:

Throughput: It improves throughput by 10 percent compared to its single-generation predecessor.
Stability: It prevents the allocation stalls that plagued earlier versions in high-concurrency environments.

Architect’s Note:

In JDK 25, G1 remains the most memory-efficient option regarding RSS. For performance-critical stacks on JDK 21+, Generational ZGC should be the baseline, provided you provision the infrastructure with at least 25 percent memory headroom.

The Architect’s Roadmap: Optimization by JDK Version

As a Principal Java Architect, I recognize that being “stuck” on a specific JDK version often involves balancing legacy stability with the need for modern performance. Here is your roadmap for optimization and troubleshooting, depending on which version of the JVM you are currently tethered to.

If you are on Java 8…

Manage the Metaspace Shift: Since the Permanent Generation was removed in JDK 8, you must monitor your native memory usage for class metadata using -XX:MaxMetaspaceSize. Avoid the “bad practice” of simply renaming old MaxPermSize flags to Metaspace without conducting a fresh analysis of your application’s class-loading needs.
Address the CMS Maintenance Gap: If you are using the Concurrent Mark Sweep (CMS) collector on free builds, be aware that it is no longer maintained and lacks critical backported patches. If performance is degrading, transition to the Parallel GC for throughput or G1 GC for a balance of latency, though be wary that G1 in the Java 8 era utilized significantly more native memory than modern versions.
Tune for Premature Promotion: If you see high Stop-The-World (STW) durations in the Old generation, increase your SurvivorRatio from the default 8:1 to 6:1. This provides more breathing room for medium-lived objects and can reduce premature promotions by up to 30%.
Leverage Performance Editions: If an upgrade is impossible, consider utilizing specialized runtimes like Liberica JDK Performance Edition, which can provide a ~10% performance boost for legacy workloads.

If you are on Java 11…

Re-evaluate Inherited Flags: Do not carry over your Java 8 tuning scripts blindly; flags that benefited the Parallel collector often conflict with the G1 GC heuristics now active by default. For example, manually setting the young generation size can prevent G1 from accurately meeting its MaxGCPauseMillis targets.
Be Cautious with Experimental ZGC: While ZGC was introduced in JDK 11, it was experimental and limited to Linux. It lacks generational capabilities in this version, making it highly susceptible to allocation stalls if your application’s allocation rate is high.
Monitor G1 Native Footprint: G1 was significantly improved in JDK 11 to reduce its native memory overhead, which was a major complaint in earlier versions. Use Native Memory Tracking (NMT) with -XX:NativeMemoryTracking=summary to ensure your container limits are not being breached by the collector’s internal data structures.

If you are on Java 17…

Commit to ZGC for Large Heaps: Since JDK 15, ZGC has been production-ready and is the primary choice for heaps ranging from 8 GB to 16 TB where sub-millisecond latency is required. However, ensure you have 15-25% memory headroom beyond your peak working set to accommodate ZGC’s concurrent relocation work and metadata.
Enable Huge Pages: On Linux, enable Transparent Huge Pages (THP) or explicit large pages to achieve a “free lunch” performance boost of approximately 10%.
Transition from CMS: If you are migrating from Java 8/11 to 17, remember that CMS was removed in JDK 14. You must move to G1 or ZGC; G1 is typically the most stable choice for memory-constrained environments where the heap-to-container ratio exceeds 80%.
Use Modern Diagnostics: Utilize JDK Flight Recorder (JFR) for profiling with less than 2% overhead to identify fine-grained allocation patterns and object creation rates.

If you are on Java 21…

Activate Generational ZGC: This is the most significant change in modern JVM performance. Use the flags -XX:+UseZGC -XX:+ZGenerational to handle high allocation rates that would have caused stalls in earlier versions. In benchmarks like Apache Cassandra, this version remains stable with up to 275 concurrent clients, whereas the non-generational version often failed at 75.
Exploit the Weak Generational Hypothesis: Generational ZGC improves throughput by 10% compared to legacy ZGC by focusing its collection efforts on the young generation where most objects “die young”.
Leverage G1 Efficiency: If your environment is extremely memory-constrained, the G1 collector in JDK 21 is more efficient than ever, as it now requires only one marking bitmap instead of two, significantly reducing its Resident Set Size (RSS).
Adopt Compact Object Headers: Consider enabling the compact object headers feature (experimental in 24, but maturing in late 21 updates) to reduce the memory footprint of every object on the heap, improving overall throughput.

Analogy: Navigating Java versions is like maintaining a building’s HVAC system. Java 8 is an old boiler where you must manually watch the pressure gauges (Metaspace and PermGen). Java 11 and 17 are modern units that work well but require you to clear out the old filters (inherited flags) to be effective. Java 21 is a smart climate control system: by enabling Generational ZGC, the system finally becomes intelligent enough to focus its energy only on the rooms currently in use (the young generation), saving you massive amounts of manual labor and resource cost.

Conclusion

There is no single “best” collector. There is only the right collector for your specific constraints.

Parallel GC is a massive double-decker bus. It carries the most passengers (throughput) but blocks all traffic when it stops. G1 is a fleet of mid-sized shuttles. They cause frequent but short delays. Generational ZGC is a network of drones. They deliver instantly, but they consume more energy and space to operate.

Align your JVM configuration with your business goals. Monitor your allocation rates using the equations provided. And most importantly, stop treating memory management as an afterthought.

References

Gullapalli, V. (2025). Adaptive JVM Optimization: Charting the Path from ParallelOld to ZGC Excellence. Al-Kindi Publisher. Journal of Computer Science and Technology Studies, 7(8).
Edelveis, C. (2024). An Overview of Java Garbage Collectors. BellSoft Corporation.
Cai, Z., Blackburn, S. M., Bond, M. D., & Maas, M. (2022). Distilling the Real Cost of Production Garbage Collectors. arXiv:2204.06782.
Johansson, S. (2023). Garbage Collection in Java: Choosing the Correct Collector. Oracle Corporation (Java YouTube Channel).
Oracle Corporation. (2023-2025). Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide, Release 21. Oracle Help Center.
Reddit Community. (2021-2025). How to choose the best Java garbage collector. r/java.
Korando, B. (2023). Introducing Generational ZGC. Inside Java.
Johansson, S. (2023). JDK 21: The GCs keep getting better. OpenJDK Performance Blog.
Ericson, A. (2021). Mitigating garbage collection in Java microservices. Mid Sweden University. DiVA portal.
Canales, F., Hecht, G., & Bergel, A. (2021). Optimization of Java Virtual Machine Flags using Feature Model and Genetic Algorithm. ACM ICPE ’21 Companion.
Diakogiannis, A. D. (2024). The Generational Z Garbage Collector (ZGC). JEE.gr.
Diakogiannis, A. D. (2017). Ta Java VM Options pou prepei na ksereis ti kanoun!. JEE.gr.

Tanja Obradovic: Jakarta EE 2025: a year of growth, innovation, and global engagement

Thu, 18 Dec 2025 14:07:09 +0000

Jakarta EE 2025: a year of growth, innovation, and global engagement

As 2025 comes to a close, it's a great moment to reflect on what we’ve achieved together as the Jakarta EE community. From major platform updates to refreshing the website and growing developer engagement, this year has been full of meaningful progress.

Celebrating Jakarta EE 11

One of our biggest milestones this year was Jakarta EE 11. This time we did the release in a different way: we released as soon as the profile or platforms were ready! The Core Profile was available in December 2024 and Web Profile in March 2025, and Jakarta EE Platform finalised in June 2025, reflecting the steady progress of the Jakarta EE community. Compatible products followed right away!

Jakarta EE 11 introduces the new Jakarta Data specification, delivers a modernised testing experience with updated TCK infrastructure based on JUnit 5 and Maven, and expands support for Java 21, including virtual threads. It also streamlines the platform by retiring older specifications such as Managed Beans, reinforcing Contexts and Dependency Injection (CDI) as the preferred programming model and continues to provide Java Records support.

This release marks a significant step forward in simplifying enterprise Java development, improving developer productivity, and supporting modern, cloud native applications. It's a true reflection of the community’s collaborative efforts and ongoing commitment to innovation.

Read the Jakarta EE 11 announcement

Introducing Jakarta Agentic AI: A New Standard for Running AI Agents on Jakarta EE

This year marked the introduction of the Jakarta Agentic AI specification project. Aimed at standardising how AI agents run within Jakarta EE runtimes, this new specification will be included in a future release. Much like Jakarta Servlet unified HTTP processing and Jakarta Batch defined batch workflows, Jakarta Agentic AI will provide a clear, annotation-driven API that defines how agents are created, managed, and executed.

Built on CDI as the core component model, the specification will establish consistent lifecycle patterns and usage semantics, making it easier for developers to implement and integrate a wide range of agent types. The project also anticipates deep integration with key Jakarta EE APIs, ensuring seamless interoperability across the platform.

Jakarta Agentic AI is being developed with broad industry collaboration in mind. The project is seeking input from subject-matter experts, vendors, and API consumers both inside and outside the Java ecosystem to build the most open, portable, and future-ready agent execution model possible. Visit the project page to learn more about the specification.

Listening and learning through the Jakarta EE Developer Survey

Our annual Jakarta EE Developer Survey remains one of the best ways to track how developers and organisations are using enterprise Java and shaping their cloud strategies. In 2025, we saw a 20% increase in participation, with over 1,700 participants sharing how they use Jakarta EE in practice.

The results show continued growth and confidence in Jakarta EE across the ecosystem. Notably, even before the full platform release was finalised, 18 percent of respondents were already using Jakarta EE 11, a strong signal of interest and early adoption.

These insights help us better understand where the community is focusing its energy, from modernising applications and adopting newer Java versions to evaluating cloud strategies and driving specification innovation. We're grateful to everyone who participated and shared their views.

Explore the 2025 developer survey findings

Learning and contributing: A growing developer ecosystem

The Jakarta EE Learn page expanded its resources to better support developers at all levels. As part of our broader effort to support community growth, we also introduced a new Contribute page, a dedicated space that outlines how individuals and organisations can get involved with Jakarta EE.

The Contribute page highlights the many ways to participate, from writing code and improving documentation to joining specification discussions or helping with community outreach. It also explains why contributing matters, what contributors gain, and how to get started.

To further support newcomers, we launched the Jakarta EE Mentorship Program, which pairs new contributors with experienced community mentors who can provide guidance, answer questions, and help them navigate the contribution process. Whether you're new to open source or simply new to Jakarta EE, the mentorship experience helps build skills, confidence, and deeper community connections.

Looking ahead: A refreshed web presence

Throughout 2025, our marketing team in collaboration with the Jakarta EE Marketing Committee worked on a major Jakarta EE website refresh to better reflect the clarity, maturity, and momentum of the community. While the full launch is now scheduled for early January, the homepage and navigation redesign is already complete and ready for rollout. The updated site features a bold new homepage, improved navigation through streamlined mega menus, and a new “Why Jakarta EE” section that helps visitors quickly understand the platform’s value.

This is just the beginning. Additional updates and structural improvements will continue rolling out through 2026, with a focus on enhancing messaging, navigation, and the overall user experience. Stay tuned for the official launch and more updates in the months ahead.

Global presence: virtual events, conferences, and community connections

Jakarta EE had a visible and impactful presence at face-to-face (F2F) conferences around the world, especially in the first half of the year. From Devnexus to JCON and beyond, Jakarta EE working group and community members presented talks, engaged with attendees at our sponsored booths, and built valuable relationships.

In 2025, JakartaOne Livestreams continued to grow with successful regional events in China and the annual JakartaOne Livestream, which attracted more than 6,000 viewers globally, with over 3,200 participants. With 20+ sessions, 15+ speakers, and 14+ hours of multilingual content, the JakartaOne Livestream series continued to drive strong community engagement across regions. Chinese JakartaOne Livestream recordings, as well as the annual JakartaOne Livestream recording, are available on our YouTube channel for anyone interested.

JakartaOne F2F Meetups further expanded the program’s regional footprint, with events in China and Japan drawing 170+ registered participants and 100+ in-person attendees, supported by high community approval and strong local participation.

With 17 Jakarta EE Tech Talks delivered in 2025, the program remains a vital channel for community learning, collaboration, and inspiration. Topics ranged from microservices and containers to security and observability. Recordings of these sessions are available on our YouTube channel.

Looking forward to 2026 and beyond

As we conclude an impactful 2025, it’s clear that Jakarta EE continues to strengthen its role as the open, vendor-neutral foundation for modern enterprise Java. The progress we’ve made this year, from delivering Jakarta EE 11 and introducing new specifications like Jakarta Agentic AI, to expanding our global events and deepening community engagement, reflects the dedication, collaboration, and passion of everyone involved.

2026 promises to be another exciting year of innovation and growth.

Thank you to all members, contributors, committers, and the wider community for your continued support. Together, we’re driving the platform forward and building a vibrant, open, and innovative ecosystem.

Here’s to another year of progress, collaboration, and innovation with Jakarta EE.

Tatjana Obradovic Thu, 2025-12-18 09:07

Víctor Orozco: Book Review: Kotlin for Java Developers

Thu, 11 Dec 2025 00:00:00 +0000

General information

Pages: 414
Published by: Packt
Release date: October 2025

Disclaimer: I received this book as part of a collaboration with Packt

TL;DR

Essentially, this is a book that uses a "problem-reasoning-solution" approach to present the building blocks that make Kotlin interesting and different from Java. Hence, it isn't:

A Kotlin reference book (i.e., it does not provide deep technical documentation)
A book for learning how to program from scratch

In my opinion, it delivers what it promises.

About the book and how I read it

I work with both Java and Kotlin professionally. However, as a technical trainer I'm always looking for educational resources that can boost students' knowledge, either as a main reference or as a complementary resource. I think this book fits the latter category.

Right from the cover, the book states its value proposition:

Confidently transition from Java to Kotlin through hands-on examples and idiomatic Kotlin practices

I believe it achieves that, although at least in the first two chapters the writing style can make the book somewhat hard to read.

A rocket that takes time to launch but can reach Mars

The book is divided into four sections:

Getting started with Kotlin
Object-Oriented Programming
Functional Programming
Coroutines, Testing and DSLs

My least favorite section was the first, especially the first two chapters. The first chapter tries to give an overview of Kotlin versus Java, but it is too superficial and perhaps even unnecessary. I imagine the goal of this chapter is to spark interest in Kotlin, but it also anticipates that everything will be covered in more detail later. Personally, I almost skipped this chapter because I knew I would see the topics in more depth later. I suppose that's a matter of taste.

Then, the second chapter sketches out Maven and Gradle without going in depth, which felt redundant since the book is targeted at Java developers. I expected more detail in this section about which plugins are used in the build process, how they interact with Maven lifecycles, and other specific topics. But the book delegates this responsibility to the IDE wizard and that's it.

From chapter three onward something magical happens. The book finally launches and its value proposition starts to materialize. Starting in chapter three the writing style changes and consistently presents concept by concept. Almost every chapter is structured like this:

A common problem is discussed, often respectfully from a Java perspective
The Kotlin design decision is presented and how it aims to improve the problem
A concise, self-contained Kotlin snippet explains the programming concept

This last part is what gives the book its value. Studying a programming language — especially when you already know how to program — is a different process than learning to program for the first time. This book recognizes that and discusses Kotlin's value propositions in technical terms, presenting self-contained snippets that readers can try in their IDE or download from the book's official repository.

If I were to use a rocket analogy, imagine that the following chapters are like Apollo 11 in full ascent from Cape Canaveral.

Part I

Null and non-nullable types
Extension Functions and the apply function

Part II

Object-Oriented programming basics
Generics and variance
Data and sealed classes

Because this is not a reference book or official documentation, up to this point the book presents each concept well without diving into corner cases — which is fine. With practice, the book can be completed in about a week and provides a solid foundation for moving to the next level, whether that's Android development or Kotlin backend programming.

From Part III there is a noticeable shift: we leave the Java-centric atmosphere and enter idiomatic Kotlin territory. Java-only developers will likely notice this change, as we move into structures that are often too abstract to have direct equivalents in Java, including:

Part III - All this in the "Kotlin way"

Basics of functional programming
Lambdas
Collections and sequences

Part IV

Coroutines
Synchronous and asynchronous programming

Finally, once we're in orbit the book presents two topics that are useful for day-to-day development but are not strictly part of the language:

Kotlin testing
Domain-specific languages (DSLs)

Things that could be improved

As with any review, this is the most difficult section to write. Besides the first two chapters, I noticed a few things that could cause confusion:

The null safety chapter omits any mention of Java's Optional
The coroutines section briefly mentions Virtual Threads but then presents Loom as a separate effort and likens it to Quasar (a library ecosystem). In reality, Virtual Threads are part of Project Loom
The book inconsistently presents different JDK recommendations across chapters; sometimes it suggests Corretto while other times it simply suggests OpenJDK
Also on the JVM side, most of the time it suggests Java 17. I imagine this was related to the time of writing. I can say that all samples worked just fine on Java 25 (the latest LTS at the time of this review), so you should be fine using that or Java 21 (officially supported by Kotlin compiler).

Most of these are not deal-breakers, this is still an enyojable book.

Who should read this book?

Java developers exploring the Kotlin ecosystem, those interested in Android development, or developers considering switching to Kotlin as their primary language

Alexius Diakogiannis: The Darkside of AI: Risks and Realities – Talk at Voxxed Days Luxembourg 2025

Mon, 01 Dec 2025 13:11:49 +0000

I’m excited to share the video recording of my talk, “The Darkside of AI: Risks and Realities,” presented at Voxxed Days Luxembourg 2025!

The rapid acceleration of Artificial Intelligence is transforming every aspect of our lives, from how we work and communicate to how we make critical decisions. While the headlines are often filled with the amazing potential and groundbreaking advancements, itâ€™s crucial to pause and critically examine the inherent risks and complexities that come with such powerful technology.

Speaker: Alexius Dionysius Diakogiannis Event: Voxxed Days Luxembourg 2025 Room: AmigaOS

What the Talk Covers

This session went beyond the hype to explore the challenging realities that AI introduces. During the talk, we dove deep into several critical areas:

Bias and Fairness: How inherited biases in training data can lead to discriminatory and unfair outcomes, perpetuating societal inequalities.
The Ethics of Autonomy: The difficult questions surrounding liability and control as AI systems become more autonomous, especially in high-stakes fields like medicine and transportation.
Security Vulnerabilities: Exploring new attack vectors, such as adversarial examples, that can subtly trick AI models, and the risk of AI-driven misinformation campaigns (deepfakes).
Socio-economic Disruption: Analyzing the impact of mass automation on the job market and the imperative for proactive reskilling and policy-making.

Thorben Janssen: AI Glossary for Java Developers

Thu, 27 Nov 2025 13:36:58 +0000

The post AI Glossary for Java Developers appeared first on Thorben Janssen.

AI introduces many new terms, acronyms, and techniques you must understand to build a good AI-based system. That makes it hard for many Java developers to learn how to integrate AI into their applications using SpringAI, Langchain4J, or some other library. I ran into the same issue when I started learning about AI. In this...

The post AI Glossary for Java Developers appeared first on Thorben Janssen.

Thorben Janssen: Offset and Keyset Pagination with Spring Data JPA

Wed, 26 Nov 2025 13:20:14 +0000

The post Offset and Keyset Pagination with Spring Data JPA appeared first on Thorben Janssen.

Pagination is a common and easy approach to ensure that huge result sets don’t slow down your application. The idea is simple. Instead of fetching the entire result set, you only fetch the subset you want to show in the UI or process in your business code. When doing that, you can choose between 2...

The post Offset and Keyset Pagination with Spring Data JPA appeared first on Thorben Janssen.

Webtide Blog: End of Life: Changes to Eclipse Jetty and CometD

Thu, 06 Nov 2025 15:36:17 +0000

Webtide (https://webtide.com) is the company behind the open-source Jetty and CometD projects. Since 2006, Webtide has fully funded the Jetty and CometD projects through services and support, including migration assistance, production support, developer assistance, and CVE resolution.

First, the change.

Starting January 1, 2026, Webtide will no longer publish releases for Jetty 9, Jetty 10, and Jetty 11, as well as CometD 5, 6, and 7 to Maven Central or other public repositories.

Take a look at the primary announcement if you’re interested.

So, the motivation.

Why we are in this situation now harks back to the beginnings of Webtide. Briefly, Greg Wilkins founded the Jetty project in 1995 as part of a contest created by Sun Microsystems for a new language called Java. For a decade, he and Jan Bartel carefully stewarded the project as part of their consulting company Mort Bay Consulting. Around the Jetty 6 timeframe, in 2006, Webtide was founded as an LLC to evolve the project further commercially. Still, at its core, the goal was to support the incredible community that had developed over the years. When I joined in 2007, we began working to join the Eclipse Foundation. We took steps to formalize our development processes, aiming to add more commercial predictability to the open-source project. Joining the Eclipse Foundation also meant adhering to their rigorous IP policy for both the Jetty codebase and its dependencies, an essential step in improving corporate uptake.

This was also the time for the project to handle the end-of-life process for Jetty 6, while establishing Jetty 7 and Jetty 8. This was the opportunity that Webtide needed to support the project’s development by offering commercial services and support for EOL Jetty 6, while focusing on supporting and funding the future of Jetty 7 and Jetty 8.

It was the crux; after careful consideration, we decided that all commercial support releases would be open-source for the benefit of all. While not a traditional business decision, it aligned with our values and dedication to the community, which was rewarded as the community continued to grow its usage of Jetty.

This worked wonderfully for almost 20 years.

Something shifted…

We started to notice a shift in the community a few years ago. For almost 20 years, the companies we spoke with valued how our support could help them become more successful, with many ultimately becoming customers who truly understood the benefits of supporting open-source. Every single one of them saw the value in releasing EOL releases freely. When I became CEO a decade ago and Webtide became 100% developer-owned and operated, we were able to continue operating in this commercial environment with ease, to such an extent that the future of Webtide and the Jetty project is assured for many years to come.

So what changed? The tone of many companies we spoke to. Increasingly, while explaining the model that served Webtide well for so many years, where I used to hear ‘That makes so much sense, this works great!’, I now hear “So it’s just free? Great, I need to check a box.” Followed up with the galling question “Could you put this policy of yours in writing on your company letterhead?”.

And today?

Twenty years ago, things were different; Maven 2 dominance was emerging, and Maven Central was gaining ubiquity. Managing transitive dependencies was novel in many circles. Managing CVEs in a corporate setting was in its infancy, particularly with Java developer software stacks.

Now, build tooling is diverse, Maven Central is a global central repository system, and corporations should have their own caching repository servers, or they really should! Even JavaEE was rebranded as Jakarta at the Eclipse Foundation. So much change, but the one I’ll highlight is the emergence of business units focused on corporate software policies, complete with BOM files containing ever more metadata and checkboxes to click, managing CVE risks associated with software developed internally. Developers, the primary people Webtide has interacted with over the years, are increasingly far removed from software maintenance activities.

Now our approach to endlessly updating EOL releases seems remarkably outdated. Look at Jetty 9, which we have been releasing since 2013. It turns out our approach of making things as easy as possible for the community, for software that should have officially gone EOL years ago, was a benefit to many, but also enabled far more to grow complacent. Instead of scheduling migrations and updating to more recent versions, we inadvertently provided an environment that allowed companies to deploy onto software well over a decade old, when newer, more performant options were readily available. Then, when security postures started changing and businesses began looking deeper into their dependencies, they realized they were using outdated software, three or more major versions behind. Then, to our shock, many are perfectly fine with that so long as it is free and someone tells them it is ok.

If we have learned one thing within this time, it is that the EOL policy needs to be so much clearer, using established industry terminology. Looking back, we have been guilty of inventing terminology and inadvertently exacerbating the situation.

What is heartening is seeing other organizations work to address EOL as well; notably, MITRE has been developing changes to the CVE system to support EOL concepts fully. If you have ever seen the text “Unsupported When Assigned” in a CVE, then you have encountered the early efforts for EOL in a CVE.

You have to applaud the efforts of businesses to prioritize security and sane open-source policies.

However, this is also a call to open-source projects like Jetty, as we are operating in a different world. Everyone understands that ‘End-of-Life’ does not mean ‘End-of-Use’. Clearly, the system for many companies has changed from a Developer Support perspective to a Security Support perspective. EOL Software support is purchased differently now. There are companies, like Sonar (formerly Tidelift), that exist to manage security metadata about open-source software, enabling companies to manage their software risk more effectively.

EOL Jetty and CometD by Webtide

To address this industry evolution, Webtide has launched a partnership program that enables businesses relying on EOL Jetty and CometD versions to obtain CVE resolutions officially and predictably.

Webtide continues to resolve CVEs and issues for EOL Jetty and CometD in support of our commercial customers. However, the resulting binaries are now distributed directly to our commercial support customers and through our partnership network. No longer are we calling software EOL but deploying to Maven Central with a nod and a wink.

Our partners are established leaders in the open-source EOL landscape, creating products that directly address the problems the security and business industries are facing.

This synergy works perfectly with Webtide, as we are the company that offers services and support on Jetty and CometD. Migrations, developer assistance, production support, and performance are the things that directly influence the ongoing development of the open-source projects we steward. We can continue to focus on our strengths, and our partners can focus on theirs.

At last, the partners!

We are pleased to announce two partnerships. With these partners, you will be able to build a secure EOL solution for your software stack, not just for your usage of Jetty or CometD. Best yet, if you are interested in Webtide’s Lifecycle Support, you can use these partner versions in conjunction with our support!

TuxCare secures the open-source software the world builds on. Today, we protect over 1.2 million workloads – keeping them secure, compliant, and unstoppable at scale. From operating systems to development libraries and production applications, we power your open-source stack with enterprise-grade security and support, including endless lifecycle extensions for out-of-support software versions, rebootless patching for every major Linux distribution, enterprise-optimized support for community Linux, and our Linux-first vulnerability scanner that cuts through the noise.

HeroDevs provides secure, long-term maintenance for open-source frameworks that have reached End-of-Life. Through our Never-Ending Support (NES) initiative, we deliver continuous CVE remediation and compliance-grade updates, allowing your team to migrate at your own pace. Our engineers monitor upstream changes, backport verified fixes, and publish fully tested binaries for seamless drop-in replacement. With NES for Jetty and NES for CometD, you can stay secure, stable, and compliant—without refactoring or rushing a migration.

If your business is interested in our partner program, please direct inquiries to partnership@webtide.com.

Wrapping it up.

One important thing to note is that Webtide will continue to support the Jetty Project with a standard open-source release process, ensuring that older versions are released to provide the community with ample time to update to newer versions through a transition period. When Jetty 13 is released, Jetty 12.1 will continue to receive updates for a period, just as Jetty 12.0 does currently. If that is six months or a year, it remains to be seen. Once we finalize this release strategy with timelines, we will make sure the community is well-informed.

Fundamentally, the change coming is that the End of Life versions for Jetty and CometD will no longer be an empty EOL notice and quiet deployments to Maven Central. It will mean EOL and provide established industry solutions to address those who need additional support.

Tanja Obradovic: Key Highlights from the 2025 Jakarta EE Developer Survey Report

Wed, 01 Oct 2025 14:09:59 +0000

Key Highlights from the 2025 Jakarta EE Developer Survey Report

The results are in! The State of Enterprise Java: 2025 Jakarta EE Developer Survey Report has just been released, offering the industry’s most comprehensive look at the state of enterprise Java. Now in its eighth year, the report captures the perspectives of more than 1700 developers, architects, and decision-makers, a 20% increase in participation compared to 2024.

The survey results give us insight into Jakarta EE’s role as the leading framework for building modern, cloud native Java applications. With the release of Jakarta EE 11, the community’s commitment to modernisation is clear, and adoption trends confirm its central role in shaping the future of enterprise Java. Here are a few of the major findings from this year’s report:

Jakarta EE Adoption Surpasses Spring

For the first time, more developers reported using Jakarta EE (58%) than Spring (56%). This clearly indicates growing awareness that Jakarta EE provides the foundation for popular frameworks like Spring. This milestone underscores Jakarta EE’s momentum and the community’s confidence in its role as the foundation for enterprise Java in the cloud era.

Rapid Uptake of Jakarta EE 11

Released earlier this year, Jakarta EE 11 has already been adopted by 18% of respondents. Thanks to its staged release model, with Core and Web Profiles first, followed by the full platform release, developers are migrating faster than ever from older versions.

Shifts in Java SE Versions

The community continues to embrace newer Java versions. Java 21 adoption leapt to 43%, up from 30% in 2024, while older versions like Java 8 and 17 declined. Interestingly, Java 11 showed a rebound at 37%, signaling that organisations continue to balance modernisation with stability.

Cloud Migration Strategies Evolve

While lift-and-shift (22%) remains the dominant approach, developers are increasingly exploring modernisation paths. Strategies include gradual migration with microservices (14%), modernising apps to leverage cloud-native features (14%), and full cloud-native builds (14%). At the same time, 20% remain uncertain, highlighting a need for clear guidance in this complex journey.

Community Priorities

Survey respondents reaffirmed priorities around cloud native readiness and faster specification adoption, while also emphasising innovation and strong alignment with Java SE.

Why This Matters

These findings highlight not only Jakarta EE’s accelerating momentum but also the vibrant role the community plays in steering its evolution. With enterprise Java powering mission-critical systems across industries, the insights from this survey provide a roadmap for organisations modernising their applications in an increasingly cloud native world.

A Call to the Community

The Jakarta EE Developer Survey continues to serve as a vital barometer of the ecosystem. With the Jakarta EE Working Group hard at work on the next release, including innovative features, there’s never been a better time to get involved. Whether you’re a developer, architect, or enterprise decision-maker, now is the perfect time to get involved:

Explore the full report
Join the Jakarta EE Working Group: Shape the platform’s future while engaging directly with the community.
Contribute: Your feedback, participation, and innovations help Jakarta EE evolve faster.

With the Jakarta EE Working Group already preparing for the next release, including new cloud native capabilities, the momentum is undeniable. Together, we are building the future of enterprise Java.

Tatjana Obradovic Wed, 2025-10-01 10:09

Mads Opheim: Switching blog engine

Tue, 03 Jun 2025 00:00:00 +0000

I recently realized that the engine that used to run this blog wasn't updated since 2020

Markus Karg: Foundation Laid for Faster Text I/O

Sat, 17 May 2025 18:06:09 +0000

Hey guys! How’s it going?

Another six months are over and you might wonder what the old shaggy prepared this time? No wonder, it certainly is another OpenJDK contribution! This time, it speeds up reading from CharSequence, and it will allow faster Write::append.

Never heard of CharSequence? Well, it’s the common interface of String, StringBuilder, CharBuffer, and quite some custom classes out there. But wait! There are other text classes than String? Maybe you never thought abot thatâ€¦ And why would you want to speed that up? Because a program never is fast enough, but more urgently, because it reduces power consumption! So, once more, we gain fun from faster apps, plus saving the climate. Ain’t that great? So read on!

So for long time, you did not think about what happens “under the hood” when you concatenated Strings, like "abc" + "def". But then someone came and told you not to do “+” but use StringBuild::append, as that would be way faster (which it was). And then someone else came and told you, that this is an urban legend, as javac meanwhile does exactly that for you (which it does). But in fact, what happens still is that (directly or indirectly) memory is allocated which is the size of "abc" plus the size of "def" (even worse, it is not even stack memory but heap memory, but let’s put that aside for today). Actually, there is even more work done: As Strings are compressed internally, an compression algorithm chimes in. And yes, that needs time and memory, and energy, too. Indeed there is even more going on internally, but more or less we could say: Concatinating Strings is effectively making a compressed copy, then throwing away both original values, even in the Java 25 age. And “throwing away” means, leaving behind holes in the linear memory space. So besides pure Garbage Collection (“vacuuming”), we need memory defragmentation (“waste grinding”), which is another nice word for: moving even more bytes around in memory. And that costs even more time and power. And guess what: Your app concatenates Strings a lot, right? And guess what: The Java Runtime (JRE) itself internally concatenates even more Strings! So copy, reallocate, compress, deallocate, GC, defrag all the time. But for what? For nothing! Sigh.

For nothing? Yes, for nothing. Because you could spare a lot of that – when further using StringBuilder instead of String. Ok, you know that since long time, so you do that, and so is javac (it replaces String+String by a StringBuilder “under good conditions”), and so is the JRE itself. But here comes the bad news: In the end, you, just like javac, just like the JRE itself, are calling toString() eventually. Don’t you? You do! And that meansâ€¦ right: Pointless power consumption, as toString() produces another temporary copy on the heap!

So why not omitting toString()? Just directly pass around your StringBuilder everywhere, instead of toString()’ing it! This spares lots of toString(). (cheer) So all is fine now? Nope. (cheer stops). Once you want to output your StringBuilder, or once you want to input text into a StringBuilder, you’re facing a problem: Your surrounding frameworks do not accept StringBuilder! Typically these all work with String, or, like in the case we’re talking about today (to finally come to the copic of today’s posting), they do accept CharSequence – but they internally toString() it.

For example: Java’s Writer classes (you know, like good old BufferedWriter, PrintWriter, and all those) just pretend to accept not only Strings (like in write(String)), but also any other kind of CharSequence (like in append(myStringBuilder)). That looks just as what we want to spare that toString() heap clutter. But wait! Take a look at the implementation firstâ€¦ it does… tada… toString()! So that nice trick that javac internally uses a StringBuilder to implement “+” is good for nothing, as finally you end up with another time-squandering copy as soon as you output the result.

But stopy crying! I am here to help! The other day Oracle kindly adopted my latest OpenJDK contribution, and this finally paves the way to fix these troubles. To understand my solution, let’s dive deeper into Writer, and why it does toString() on any CharSequence (even on Strings themselves). The cause is: Performance. Shocking! If you copy text “char-by-char” this would be totally slow, as computers can pass around much larger clusters of information with a single command. So what Writer::write internally does is, it asks the String to put all its characters into a char array with a single command (which ontop is lightning-fast machine code ). That command is String::getChars(int, int, char[], int). So why doing that only with Strings, but not with other CharSequences? Because CharSequence does not have that command. It’s as embarrasing as that! CharSequence only can be asked for one character at a time, so you need a loop in Java – which means, in 99% of you cases, an interpreted loop (unless you do it 10.000 times to get it hot spotted eventually). And that is not just slow, it is even super-slow!

So what I did is that I added that exact getChars(int, int, char[], int) method signature that String always had to the CharSequence interface. Sounds easy, but took six months of discussions and a lot of convincing (for example, I had to proof that “not many” code exists on earth that already has such a method but that method does something else – as that code would silently do the wrong thing once executed on Java 25). This foundational change is now found in Java 25, and if you download a pre-release build, you can play with it right now – or already prepare your application if it does a “char-by-char” loop or temporary toString() currently.

So what about Writer? I’m working on it. Just today I filed the first of a set of pull requests towards getting this new method used in all Writers in OpenJDK. So while nothing will get faster “magically” in JDK 25, the foundation is laid, and by the time, eventually your code runs more efficient, without recompiling it. So… stay tunedâ€¦!

Dmitry Kornilov: Building AI Assistant Application in Java

Fri, 16 May 2025 12:57:52 +0000

In my previous article, I discussed how Helidon integrates with LangChain4J. While the article provided a solid foundation, some readers pointed out the lack of a complete, hands-on example. This time, we’ll fix that by building a fully functional, practical AI-powered Java application.

We’ll create the Helidon Assistant — a chatbot with a web UI trained to answer questions about the Helidon framework. By “trained,” I mean it will be capable of answering questions based on the full Helidon documentation.

In this article, we’ll explore how to preprocess AsciiDoc files for ingestion into an embedding store and how to make the application stateless using an AI-powered summarization mechanism. Let’s dive in!

The Project Overview

The Helidon Assistant is built with the following technologies:

Java 21
Helidon SE 4 as the runtime
LangChain4J for AI integration
In-memory Embedding Store for storing and retrieving document embeddings
OpenAI GPT-4o as the default chat model
Helidon SE static content feature for serving the web UI
Bulma CSS framework for clean and minimalistic UI styling

The application is organized into three main layers:

RESTful Service Layer – defines the public REST API and serves the web UI.
AI Services Layer – defines LangChain4J AI services: one for answering user questions, and another for summarizing the conversation.
RAG Layer – handles ingestion: reading AsciiDoc files, preprocessing content, creating embeddings, and storing them in the embedding store.

The architecture diagram is shown below:

Building and Running the Project

The project is available on GitHub here. You can either clone the repository or browse the sources directly on GitHub. I’ll refer to it throughout the article.

Before building and running the project, you need to configure the path to the AsciiDoc documentation the assistant will work with. If you already have the documentation locally—great! If not, you can clone the Helidon repository from GitHub:

git clone https://github.com/helidon-io/helidon.git

The documentation files are located in docs/src/main/asciidoc/mp.

Next, update the application configuration file located at src/main/resources/application.yaml with the path to your AsciiDoc files:

app:
  root: "//home/dmitry/github/helidon/docs/src/main/asciidoc/mp"
  inclusions: "*.adoc"

Make sure to adjust the root path to match your local environment. You can also use the inclusions and exclusions properties to filter which files under the root directory should be included during ingestion.

Now you’re ready to build the application:

mvn clean package

And launch it:

java -jar target/helidon-assistant.jar

Once running, open your browser and go to http://localhost:8080. You’ll be greeted with the assistant’s web interface, where you can start asking questions.

Here are a few example questions to get you started:

How to use metrics with Helidon?
What does the @Retry annotation do?
How can I configure a web server?
How can I connect to a database?

In the next section, we’ll take a closer look at the build script and project dependencies.

Dependencies

The project uses a standard Maven pom.xml configuration recommended for Helidon SE applications, with several additional dependencies specific to this use case. Below is a commented snippet explaining the purpose of each dependency:

<dependencies>
  <!-- Helidon integration with LangChain4J -->
  <dependency>
    <groupId>io.helidon.integrations.langchain4j</groupId>
    <artifactId>helidon-integrations-langchain4j</artifactId>
  </dependency>

  <!-- OpenAI provider: required for using the GPT-4o chat model.
       Replace this with another provider if using a different LLM. -->
  <dependency>
    <groupId>io.helidon.integrations.langchain4j.providers</groupId>
    <artifactId>helidon-integrations-langchain4j-providers-open-ai</artifactId>
  </dependency>

  <!-- LangChain4J embeddings model used for RAG functionality -->
  <dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-embeddings-all-minilm-l6-v2</artifactId>
  </dependency>

  <!-- AsciidoctorJ: used to parse and process AsciiDoc documentation files -->
  <dependency>
    <groupId>org.asciidoctor</groupId>
    <artifactId>asciidoctorj</artifactId>
    <version>${version.lib.asciidoctorj}</version>
  </dependency>

  <!-- Various Helidon dependencies needed for the application proper
       functionality -->
  <dependency>
    <groupId>io.helidon.webserver</groupId>
    <artifactId>helidon-webserver</artifactId>
  </dependency>
  <dependency>
    <groupId>io.helidon.webserver</groupId>
    <artifactId>helidon-webserver-static-content</artifactId>
  </dependency>
  <dependency>
    <groupId>io.helidon.http.media</groupId>
    <artifactId>helidon-http-media-jsonp</artifactId>
  </dependency>
  <dependency>
    <groupId>io.helidon.config</groupId>
    <artifactId>helidon-config-yaml</artifactId>
  </dependency>

  <!-- Logging -->
  <dependency>
    <groupId>io.helidon.logging</groupId>
    <artifactId>helidon-logging-jul</artifactId>
    <scope>runtime</scope>
  </dependency>
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-jdk14</artifactId>
    <scope>runtime</scope>
  </dependency>
</dependencies>

You can use these dependencies for other AI-powered projects with minimal changes.

Application main class

The ApplicationMain class serves as the application’s entry point. It contains the main method, which performs the following steps:

Enables runtime logging.
Loads the application configuration.
Ingests documentation into the embedding store.
Sets up web server routing to serve static web pages and handle user requests.
Starts the web server.

Below is a snippet of the main method:

public static void main(String[] args) {
    // Make sure logging is enabled as the first thing
    LogConfig.configureRuntime();

    var config = Services.get(Config.class);

    // Initialize embedding store
    Services.get(DocsIngestor.class)
            .ingest();

    // Static content setup
    var staticContentFeature = StaticContentFeature.builder()
            .addClasspath(cl -> cl.location("WEB")
                    .context("/ui")
                    .welcome("index.html"))
            .build();

    // Initialize and start web server
    WebServerConfig.builder()
            .addFeature(staticContentFeature)
            .config(config.get("server"))
            .routing(ApplicationMain::routing)
            .build()
            .start();
}

In the next section, I’ll explain how the embedding store is created and initialized.

Preparing AsciiDoc Files for Embeddings

Although AsciiDoc is lightweight and human-readable, the source content isn’t immediately ready for use in AI-powered retrieval. AsciiDoc files often contain structural directives like include statements, developer comments, attribute substitutions, and variables intended for conditional rendering or reuse. These elements are meaningful for human readers or documentation generators but can confuse or mislead a language model if left unprocessed. Additionally, formatting artifacts and metadata can introduce noise. Without proper preprocessing, the resulting embeddings might be irrelevant or misleading, which degrades the quality and accuracy of the assistant’s responses.

To address this, we apply a structured preprocessing pipeline.

AsciiDocJ Integration: We use the official AsciiDocJ parser to fully parse AsciiDoc documents. This library resolves include directives automatically and gives us a structured representation of the content.
Section-Based Chunking: We group content elements by their surrounding section and generate one embedding per section. This preserves logical and thematic boundaries and helps ensure responses remain relevant.
Preserve Atomic Elements: We make sure that tables and code snippets are not split across chunks. This is critical to retain the contextual meaning of examples and structured content.
Attach Metadata: Each chunk is enriched with metadata such as document title, relative file path, and section index. This helps reconstruct the document context when presenting answers.
Repeat for Each File: This process is repeated for each .adoc file identified by the inclusion pattern in the configuration.

This preprocessing ensures that the AI retrieves precise, coherent documentation segments in response to user queries, resulting in more accurate and helpful answers.

Here’s how the implementation is structured:

AsciiDocPreprocessor.java parses the file and produces a list of document chunks.
ChunkGrouper.java groups chunks into section-based logical units.
FileLister.java reads the directory path and applies inclusion/exclusion patterns.
DocsIngestor.java orchestrates the overall process: listing files, extracting and grouping chunks, converting them to TextSegment objects, and storing the resulting embeddings.

A simplified snippet from DocsIngestor.java demonstrates the ingestion logic:

public void ingest() {
    var files = FileLister.listFiles(root, exclusions, inclusions);
    var processor = new AsciiDocPreprocessor();
    var grouper = new ChunkGrouper(1000);

    for (Path path : files) {
        var chunks = processor.extractChunks(path.toFile());
        var groupedChunks = grouper.groupChunks(chunks);

        List<TextSegment> segments = new ArrayList<>();
        for (int i = 0; i < groupedChunks.size(); i++) {
            var chunk = groupedChunks.get(i);
            var metadata = new Metadata()
                    .put("source", path.toFile().getAbsolutePath())
                    .put("chunk", String.valueOf(i + 1))
                    .put("type", chunk.type().name())
                    .put("section", chunk.sectionPath());

            segments.add(TextSegment.from(chunk.text(), metadata));
        }

        var embeddings = embeddingModel.embedAll(segments);
        embeddingStore.addAll(embeddings.content(), segments);
    }
}

Serving static web pages

The UI consists of a single index.html file located in the resources/WEB directory. It’s styled using the Bulma CSS framework, which is designed to be JavaScript free.

But there is a small piece of the JavaScript code anyway. It sends user messages to the backend when the Send button is clicked, updates the chat window with the response, and manages conversation summary state.

To serve this page, we register a StaticContentFeature during the web server startup. The code below demonstrated how it’s done in the main method.

// Static content setup
var staticContentFeature = StaticContentFeature.builder()
        .addClasspath(cl -> cl.location("WEB")
                .context("/ui")
                .welcome("index.html"))
        .build();

// Initialize and start web server
WebServerConfig.builder()
        .addFeature(staticContentFeature)
        ...

/ui path is registered to serve the static content. It user tries to open another path, he will be redirected to /ui. It’s done in the routing method.

static void routing(HttpRouting.Builder routing) {
    routing.any("/", (req, res) -> {
                // showing the capability to run on any path, and redirecting from root
                res.status(Status.MOVED_PERMANENTLY_301);
                res.headers().set(UI_REDIRECT);
                res.send();
            })
            .register("/chat", Services.get(ChatBotService.class));
}

Processing user requests

When the user clicks the Send button in the UI, a server call to the /chat endpoint is initiated. This request sends the user’s message along with a conversation summary to the server. We’ll discuss conversation summaries in a later section—let’s first focus on how the request is processed on the server side.

User requests to /chat are handled by the ChatBotService.java class. This class is registered during web server initialization, as shown in ApplicationMain.java. Below is a simplified snippet that demonstrates how it’s done:

static void routing(HttpRouting.Builder routing) {
    routing.register("/chat", Services.get(ChatBotService.class));
    ...
}

The ChatBotService class contains the chatWithAssistant method, which handles incoming requests. It performs the following steps:

Extracts the user’s message and conversation summary from the request.
Invokes ChatAiService, passing the message and summary to generate a response.
Uses SummaryAiService to create an updated conversation summary.
Builds a JSON object containing the response and the updated summary, and sends it back to the client.

Here’s the simplified code for the chatWithAssistant method:

private void chatWithAssistant(ServerRequest req, ServerResponse res) {
    var json = req.content().as(JsonObject.class);
    var message = json.getString("message");
    var summary = json.getString("summary");

    var answer = chatAiService.chat(message, summary);
    var updatedSummary = summaryAiService.chat(summary, message, answer);

    var returnObject = JSON.createObjectBuilder()
                .add("message", answer)
                .add("summary", updatedSummary)
                .build();
    res.send(returnObject);
}

The ChatAiService.java class is implemented as a Helidon AI service. You can learn more about AI services and how to implement them in my previous article.

Here’s the relevant code:

@Ai.Service
public interface ChatAiService {

    @SystemMessage("""
            You are Frank, a helpful Helidon expert.

            Only answer questions related to Helidon and its components. If a question is not relevant to Helidon, 
            politely decline.

            Use the following conversation summary to keep context and maintain continuity:
            {(summary})
            """)
    String chat(@UserMessage String question, @V("summary") String previousConversationSummary);
}

Making the Application Stateless

In a typical chat application, the backend must maintain the full history of the conversation in order to understand the user’s intent. This is because language models like OpenAI’s GPT rely heavily on context — they need to see the dialogue leading up to the current question to provide an accurate and helpful answer. The longer and more complex the conversation, the more memory is required to hold that context.

However, storing chat history introduces challenges. If you’re running a single backend instance, you might store this state in memory. But in a production environment, especially in cloud-native deployments, applications often scale horizontally — meaning multiple instances of the backend may be running behind a load balancer. In such setups, traditional in-memory storage for chat history doesn’t work: the next request from the same user might be routed to a different backend instance that has no access to prior state.

This is where statelessness becomes critical. Stateless services are inherently scalable, easier to maintain, and more resilient. But to make a chatbot stateless without sacrificing conversation quality, we need a way to preserve and compress context — and that’s where AI-powered summarization comes in.

By summarizing the chat history into a compact form after every message, we replace a long list of messages with a lightweight, synthetic memory that still captures the user’s intent and context. This summary is sent along with the next message, enabling consistent, relevant responses while allowing each request to be handled independently.

The Helidon Assistant uses this technique to remain stateless and cloud-native, ensuring it can scale easily while maintaining meaningful conversations with users.

Summarizer implemented as an AI service. You can read more about AI services and how to implement them in my previous article.

@Ai.Service
public interface SummaryAiService {

    @SystemMessage("""
        You are a conversation summarizer for an AI assistant. Your job is to keep a concise summary of the
        ongoing conversation to preserve context.
        Given the previous summary, the latest user message, and the AI's response, update the summary so it
        reflects the current state of the conversation.
        Keep it short, factual, and focused on what the user is doing or trying to achieve. Avoid rephrasing the
        entire response or repeating long parts verbatim.
        """)
    @UserMessage("""
        Previous Summary: 
        {{summary}}

        Last User Message:
        {{lastUserMessage}}

        Last AI Response:
        {{aiResponse}}
        """
    )
    String chat(@V("summary") String previousSummary,
                @V("lastUserMessage") String latestUserMessage,
                @V("aiResponse") String aiResponse);
}

Wrapping Up

That’s it — we’ve built a fully working, stateless AI assistant powered by Helidon and LangChain4J. Hopefully, everything is clear and nothing important was left out. But if something feels confusing or needs more explanation, I’d love to hear your thoughts. Feedback is always welcome — whether it’s a bug, a missing step, or just a better way to do things.

Want to dive into the code or try it yourself? You’ll find everything here:

GitHub: Helidon Assistant

Thanks for reading — and happy coding!

Mads Opheim: Replace simple sub-GitHub Actions with plain run

Wed, 23 Apr 2025 00:00:00 +0000

Use the GH CLI directly instead of wrappers you don't need

Francesco Marchioni: How to run WildFly applications with JBang

Sun, 13 Apr 2025 14:39:25 +0000

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.

Víctor Orozco: Install VirtualBox over Fedora with SecureBoot enabled

Mon, 24 Mar 2025 00:00:00 +0000

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:

RPM Fusion is a community repository for Enterprise Linux (Fedora, RHEL, etc.) that provides packages not included in official distributions.
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.

Dmitry Kornilov: Developing AI-Powered Applications with Helidon and LangChain4J

Thu, 13 Mar 2025 13:33:23 +0000

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.

Annotation	Description
Ai.ChatModel	Specifies the name of a service in the service registry that implements ChatModel to be used in the annotated AI Service. Mutually exclusive with Ai.StreamingChatModel.
Ai.StreamingChatModel	Specifies the name of a service in the service registry that implements StreamingChatModel to use in the annotated Ai Service. Mutually exclusive with Ai.ChatModel.
Ai.ChatMemory	Specifies the name of a service in the service registry that implements ChatMemory to use in the annotated Ai Service. Mutually exclusive with Ai.ChatMemoryWindow and Ai.ChatMemoryProvider.
Ai.ChatMemoryWindow	Adds a MessageWindowChatModel with the specified window size to the annotated AI Service. Mutually exclusive with Ai.ChatMemory and Ai.ChatMemoryProvider.
Ai.ChatMemoryProvider	Specifies the name of a service in the service registry that implements ChatMemoryProvider to use in the annotated Ai Service. Mutually exclusive with Ai.ChatMemory and Ai.ChatMemoryWindow.
Ai.ModerationModel	Specifies the name of a service in the service registry that implements ModerationModel to use in the annotated Ai Service.
Ai.ContentRetriever	Specifies the name of a service in the service registry that implements ContentRetriever to use in the annotated Ai Service. Mutually exclusive with Ai.RetrievalAugmentor.
Ai.RetrievalAugmentor	Specifies the name of a service in the service registry that implements RetrievalAugmentor to use in the annotated Ai Service. Mutually exclusive with Ai.ContentRetriever.

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:

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:

Jakarta EE Ambassadors: Jakarta EE Ambassadors Gather at Devnexus 2025 to Deliver Sessions on Jakarta EE

Mon, 03 Mar 2025 16:54:34 +0000

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 Cajas Duke 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.

Francesco Marchioni: What is new in Jakarta Persistence 3.2

Sun, 24 Nov 2024 17:08:04 +0000

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.

Markus Karg: Reader.of(CharSequence)

Sat, 02 Nov 2024 13:21:36 +0000

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!

Webtide Blog: Back to the Future with Cross-Context Dispatch

Thu, 16 May 2024 01:31:21 +0000

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.

Jan Supol: HTTP Patch with Jersey Client on JDK 16+

Fri, 26 Apr 2024 11:26:35 +0000

Jakarta REST provides a Client API, implemented by Jersey Client. The default implementation is based on the Java HttpUrlConnection. Unfortunately, the HttpUrlConnection supports only HTTP methods defined in the original HTTP/1.1 RFC 2616. It will never support for instance HTTP … Continue reading →

Jean-François James: Monitoring Java Virtual Threads

Wed, 10 Jan 2024 17:14:14 +0000

Introduction In my previous article, we’ve seen what Virtual Threads (VTs) are, how they differ from Platform Threads (PTs), and how to use them with Helidon 4. In simple terms, VTs bring in a new concurrency model. Instead of using many PTs that can get blocked, we use a few of them that hardly ever […]

Tomitribe: Moving from javax to jakarta namespace

Thu, 12 Oct 2023 14:32:06 +0000

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.

Jean-François James: Running MicroProfile reactive with Helidon Nima and Virtual Threads

Wed, 20 Sep 2023 17:29:53 +0000

I recently became interested in Helidon as part of my investigations into Java Loom. Indeed, version 4 is natively based on Virtual Threads. Before going any further, let’s introduce quickly Helidon. Helidon is an Open Source (source on GitHub, Apache V2 licence) managed by Oracle that enables to develop lightweight cloud-native Java application with fast […]

Mike Milinkovich: New Survey: How Do Developers Feel About Enterprise Java in 2023?

Tue, 19 Sep 2023 13:00:00 +0000

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.

Reza Rahman: Jakarta EE and MicroProfile at EclipseCon Community Day 2022

Sat, 19 Nov 2022 22:39:02 +0000

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.

Ivo Woltring: JFall 2022

Fri, 04 Nov 2022 09:56:09 +0000

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.

Mike Milinkovich: Survey Says: Confidence Continues to Grow in the Jakarta EE Ecosystem

Mon, 26 Sep 2022 13:00:00 +0000

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.

Jakarta EE Ambassadors: Jakarta EE 10 has Landed!

Thu, 22 Sep 2022 15:48:16 +0000

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!

Vladimir V. Bychkov: Java Reflections unit-testing

Wed, 13 Jul 2022 21:06:18 +0000

How make java code with reflections more stable? Unit tests can help with this problem. This article introduces annotations @CheckConstructor, @CheckField, @CheckMethod to create so unit tests automatically

Ivo Woltring: Java EE - Jakarta EE Initializr

Thu, 05 May 2022 14:23:40 +0000

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!

Reza Rahman: FOSDEM 2022 Conference Report

Mon, 21 Feb 2022 00:24:38 +0000

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.

Sergii Kostenko: Infinispan Apache Log4j 2 CVE-2021-44228 vulnerability

Sun, 12 Dec 2021 22:00:00 +0000

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

Vladimir V. Bychkov: JPA query methods: influence on performance

Thu, 18 Nov 2021 07:22:25 +0000

Specification JPA 2.2/Jakarta JPA 3.0 provides for several methods to select data from database. In this article we research how these methods affect on performance

Tomitribe: Custom Identity Store with Jakarta Security in TomEE

Thu, 30 Sep 2021 11:42:38 +0000

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.

Sergii Kostenko: Undertow AJP balancer. UT005028: Proxy request failed: java.nio.BufferOverflowException

Fri, 02 Apr 2021 21:00:00 +0000

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)

Elder Moraes: Jakarta EE Cookbook

Mon, 06 Jul 2020 19:19:50 +0000

About one month ago I had the pleasure to announce the release of the second edition of my book, now called “Jakarta EE Cookbook”. By that time I had recorded a video about and you can watch it here:

[embedyt] https://www.youtube.com/watch?v=SFbDs1HKEyA[/embedyt]

And then came a crazy month and just now I had the opportunity to write a few lines about it!

So, straight to the point, what you should know about the book (in case you have any interest in it).

Target audience

Java developers working on enterprise applications and that would like to get the best from the Jakarta EE platform.

Topics covered

I’m sure this is one of the most complete books of this field, and I’m saying it based on the covered topics:

Server-side development
Building services with RESTful features
Web and client-server communication
Security in the enterprise architecture
Jakarta EE standards (and how does it save you time on a daily basis)
Deployment and management using some of the best Jakarta EE application servers
Microservices with Jakarta EE and Eclipse MicroProfile
CI/CD
Multithreading
Event-driven for reactive applications
Jakarta EE, containers & cloud computing

Style and approach

The book has the word “cookbook” on its name for a reason: it follows a 100% practical approach, with almost all working code available in the book (we only omitted the imports for the sake of the space).

And talking about the source code being available, it is really available on my Github: https://github.com/eldermoraes/javaee8-cookbook

PRs and Stars are welcomed!

Bonus content

The book has an appendix that would be worthy of another book! I tell the readers how sharing knowledge has changed my career for good and how you can apply what I’ve learned in your own career.

Surprise, surprise

In the first 24 hours of its release, this book simply reached the 1st place at Amazon among other Java releases! Wow!

Of course, I’m more than happy and honored for such a warm welcome given to my baby…

If you are interested in it, we are in the very last days of the special price in celebration of its release. You can take a look here http://book.eldermoraes.com

Leave your comments if you need any clarification about it. See you!

Philip Riecks: Jakarta EE 8 CRUD API Tutorial using Java 11

Sun, 19 Jan 2020 15:07:54 +0000

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