Forem: Shaaf Syed

Modernizing Legacy Code with Konveyor AI: From EJB to Kubernetes

Shaaf Syed — Wed, 15 Apr 2026 11:06:09 +0000

I always enjoy participating in KubeCon. This time it was at the RAI center in Amsterdam. I have been to many conferences and the ones that are the best IMHO are the ones that are very community focused. For example DevNexus for Java, GeeCon for Geeks ;), and obviously KubeCon for everything Kubernetes. And obvsiouly making new friends and connections is a great way of learning from all the cool stuff thats going on. Thats probably enough name dropping for a wednesday ;)

I had the opportunity to represent the Konveyor Community project update.

Modernizing Legacy Code with Konveyor AI: From EJB to Kubernetes

"We want to have a meaningful result out of generative AI, not just chatting around... we can context engineer that code, send it into the LLM, and get results integrated back into the codebase." — Shaaf Syed

Application modernization is a daunting task, especially when dealing with legacy codebases that are decades old. In my recent CNCF Project Lightning Talk, I introduced how the Konveyor community is leveraging AI and static analysis to automate this process for almost any programming language. While there are multiple ways of solving the migration and modernization challenges, Konveyor community takes a unique approach to it.

For example many enterprises still rely on 30-year-old Enterprise Java Beans (EJB) or legacy protocols like RMI/IIOP. When leadership asks to move these applications to Kubernetes, developers face a nightmare of serialization issues, stubs, and complex clustering logic that simply doesn't fit a modern cloud-native environment. It like you just encountered the "Legacy Wall!". Nothing can get passed that point. True, but hardly anymore IMHO. Why not use the traditional static code anaylsis to enahnce the responses of an LLM.

During the talk, I demonstrated a live example of an outdated EJB, i.e. being transformed into a modern REST service. What would normally take hours of manual refactoring was reduced to a generated Git patch that the developer could simply review and apply.

Konveyor solves this by combining deep static code analysis with the power of Large Language Models (LLMs). The core workflow involves:

Static Code Analysis: The engine analyzes source code (Java, Go, Python, NodeJS, etc.) to identify "incidents"—specific lines of code that won't run on Kubernetes.
Context Engineering: By understanding the code paths via the Language Server Protocol (LSP), Konveyor provides the necessary context to an LLM.
Automated Remediation: Instead of just chatting, the AI generates meaningful code fixes, such as replacing legacy protocols with REST endpoints or suggesting the use of Kubernetes Secrets and ConfigMaps.

Beyond Chat: Agents and Memory

What makes Konveyor AI particularly powerful is its move toward Agentic AI and Distributed Memory:

1. Agentic Validation

When AI fixes one part of the code, it often breaks another. Konveyor’s agents handle:

Compilation: Ensuring the new code actually builds.
Validation Testing: Running tests to verify functionality.
Sanitization: Cleaning up the output before it reaches the developer.

2. Organizational Memory

If a developer modifies an AI-generated fix (e.g., changing how exceptions are handled), Konveyor can "remember" that preference. This memory is shared across the organization, so future migrations automatically follow the team's specific coding standards.

Get Involved

Konveyor is an open-source community project. You can find them at their CNCF kiosk or join the community to help build the future of automated application modernization.

Nano Agent, Mega Senses: Adding LSP to the 260-Line Coding Agent

Shaaf Syed — Fri, 10 Apr 2026 05:19:09 +0000

Learn, learn, and learn more—that’s the name of the game. Coding agents are innovating fast; things are getting bigger and, quite often, bloated. To understand what an agent is actually doing, I’ve found it’s best to go back to the basics. It takes a bit more time, but the expertise you gain along the way sets you up for the long haul." So here I read Max's post and thought, how about add some more things to this. Fetching ideas... done.. Lets add LSP support.

The original nanocode idea is easy to lose in the hype: a coding agent is mostly a loop. You send prompt plus tool definitions to the model; the model answers with text or tool calls; you execute tools, feed results back, and repeat. The heavy lifting is the model; your code is hands (write, edit, shell) and eyes (read, glob, grep).

That pattern is how “real” agents are structured too — usually with more polish, safety rails, and often richer senses than plain text search.

This fork keeps that loop and the same six core tools. It adds an optional extra sense for Java workspaces: a language server, so the model can ask project-aware questions instead of inferring everything from raw files.

Does LSP fits the same architecture?

grep and read are universal and powerful. They are also syntax-blind. A symbol might be a field, a local, an import alias, or a string that happens to match. For Java — especially with Maven or Gradle classpaths — the compiler’s view of the project is not the same as “all lines containing this word.”

The Language Server Protocol is the boring industry answer: one process holds the classpath, incremental errors, types, and navigation graph; the client sends small questions (go to definition, hover, publishDiagnostics) and gets structured answers.

nanocode is a thin client in that sense: it forwards requests and prints results. Wiring Eclipse JDT Language Server (the same engine behind most Java editor extensions) is not a different kind of product — it is narrower, deeper vision for one language, and stays optional so a “single-file story” remains when you do not need Java semantics.

What this fork adds (in practice)

Detection — If the workspace contains .java files, nanocode can offer to turn Java support on.
Local install — On consent (or via an environment flag), it downloads JDT LS once into your user cache (~/.cache/nanocode or $XDG_CACHE_HOME/nanocode), not into the repo.
Process + protocol — A small LSP4J client drives the server; documents are synced before semantic queries so answers match what is on disk.
Three extra tools the model sees only when LSP is enabled:
- java_definition — Where is this name bound? (1-based line/column, like many editors.)
- java_hover — Tooltip-grade material: Javadoc, type hints, etc.
- java_diagnostics — Compiler and analysis diagnostics for one file, or a roll-up across files the server has published.

The main script grew; supporting code lives alongside it so newcomers can still read the core agent in one place.

  /**
   * Dispatch tool calls to their respective implementations.
   *
   * Routes tool execution based on the tool name. Basic tools (read, write, edit, glob, grep, bash)
   * are always available. Java LSP tools (java_definition, java_hover, java_diagnostics) require
   * the javaLsp flag to be enabled.
   *
   * @param name The name of the tool to execute
   * @param args JSON arguments for the tool
   * @param javaLsp Whether Java LSP tools are enabled
   * @return Tool execution result, or error message prefixed with ERROR_PREFIX
   */
  static String runTool(String name, JsonNode args, boolean javaLsp) {
      try {
          return switch (name) {
              // Basic file and search tools
              case "read" -> toolRead(args);
              case "write" -> toolWrite(args);
              case "edit" -> toolEdit(args);
              case "glob" -> toolGlob(args);
              case "grep" -> toolGrep(args);
              case "bash" -> toolBash(args);

              // Java LSP tools - require javaLsp flag
              case "java_definition" -> {
                  if (!javaLsp)
                      yield ERROR_PREFIX + "Java LSP not enabled";
                  yield toolJavaDefinition(args);
              }
              case "java_hover" -> {
                  if (!javaLsp)
                      yield ERROR_PREFIX + "Java LSP not enabled";
                  yield toolJavaHover(args);
              }
              case "java_diagnostics" -> {
                  if (!javaLsp)
                      yield ERROR_PREFIX + "Java LSP not enabled";
                  yield toolJavaDiagnostics(args);
              }

              default -> ERROR_PREFIX + "unknown tool " + name;
          };
      } catch (Exception e) {
          // Catch all exceptions and return as error message
          return ERROR_PREFIX + e.getMessage();
      }
  }

  /**
   * Java LSP tool: Go to the definition of a symbol at the specified location.
   *
   * @param args JSON with path (required), line (default 1), column (default 1)
   * @return Location information for the symbol's definition
   */
  static String toolJavaDefinition(JsonNode args) throws Exception {
      return JavaLspSupport.definition(args.get("path").asText(), args.path("line").asInt(1),
              args.path("column").asInt(1));
  }

  /**
   * Java LSP tool: Get type information, signature, and documentation for a symbol at cursor.
   *
   * @param args JSON with path (required), line (default 1), column (default 1)
   * @return Type info, Javadoc, and signature details for the symbol
   */
  static String toolJavaHover(JsonNode args) throws Exception {
      return JavaLspSupport.hover(args.get("path").asText(), args.path("line").asInt(1),
              args.path("column").asInt(1));
  }

  /**
   * Java LSP tool: Get compiler errors and warnings for a file or all cached files.
   *
   * @param args JSON with optional path (empty string = all cached diagnostics)
   * @return List of compiler/LSP diagnostics
   */
  static String toolJavaDiagnostics(JsonNode args) throws Exception {
      return JavaLspSupport.diagnostics(args.path("path").asText(""));
  }

Examples (prompts that now “make sense”)

These are the sorts of tasks where text tools alone are brittle, but JDT + the loop line up nicely.

Navigate instead of guessing

“In src/main/java/.../OrderService.java, around line 48, what type is discount? Use java_hover at that position, then java_definition if it is a field.”

The model no longer has to re-derive the type from imports and local inference across half a dozen files unless it wants to double-check.

Errors with a real classpath

“Run java_diagnostics on PaymentMapper.java and fix whatever JDT reports; then run mvn -q test in bash.”

Diagnostics are tied to how the project is built, not to “did my regex find the word error in the log.”

Onboarding a module

“I’m new to this package. Summarize the main entry points: use glob for *Application.java, read those files, and for the class that implements Runnable or hosts main, show java_hover on the superclass or key API types.”

Read + LSP combine the way humans use an IDE: skim files, drill into symbols.

Guardrails before a large edit

“Before we rename this method, list java_diagnostics for the whole workspace (no path) and tell me if anything is already red.”

You still do not get a one-click rename refactor in this fork — but you get honest compiler state, which is often enough to avoid stepping on a broken build.

────────────────────────────────────────────────────────────────────────────────
❯ What does `GET_USERS` mean in `KeycloakOperation`?
────────────────────────────────────────────────────────────────────────────────

⏺ Java_hover(src/main/java/dev/shaaf/keycloak/mcp/server/KeycloakOperation.java)
  ⎿  dev ... +1 lines

⏺ Glob(**/KeycloakOperation.java)
  ⎿  ./src/main/java/dev/shaaf/keycloak/mcp/server/KeycloakOperat...

⏺ Read(src/main/java/dev/shaaf/keycloak/mcp/server/KeycloakOperation.java)
  ⎿     1| package dev.shaaf.keycloak.mcp.server; ... +67 lines

⏺ `GET_USERS` in the `KeycloakOperation` enum is a constant that represents an operation related to retrieving a list of users from the Keycloak server. This operation is part of a group of user operations defined in the enum, which allows users of the `KeycloakTool` to easily reference and execute actions related to user management, such as creating, updating, deleting users, and retrieving user details.

To ground this in something non-trivial, the same Java LSP stack was exercised against keycloak-mcp-server: a Quarkus-based MCP server on Java 21, Maven BOM, and many command classes under dev.shaaf.keycloak.mcp.server. Typical results: clean diagnostics on command base classes, classpath-backed hover on ObjectMapper (Jackson JAR version matching the build), and definition jumping to the real KeycloakCommand source — the sort of answers grep alone cannot guarantee.

Trying JDT without an LLM API key: the fork ships LspProbe.java (JBang), a tiny harness that calls the same JavaLspSupport as nanocode’s java_* tools. From the nanocode repo:

jbang run LspProbe.java /path/to/your-maven-project

(optional: LSP_PROBE_SYNC_SEC to tune wait for Maven sync.) First run may download JDT (~50 MB) into ~/.cache/nanocode/; after that you can confirm hover, definition, and diagnostics on disk before wiring up ANTHROPIC_API_KEY, OPENROUTER_API_KEY, or OPENAI_API_KEY.

Trade-offs worth saying out loud

Weight — JDT LS is not a toy; it is a real JVM product. The agent stays teachable; the server is the same class of dependency serious Java tooling already uses.
Tokens — A richer tool list and longer system text cost a little each request; targeted LSP results can replace huge file reads. Net savings are not guaranteed.
Trust — bash remains full power. LSP does not sandbox anything; it mainly reduces wrong guesses.
Nano -- Nano but at about 4x more code from the original port.

Read it, run it, break it, extend it. It’s a great way to understand how tools like Claude Code, Cursor, and Co Pilot work under the hood. -- Max

Java + LLMs: A hands-on guide to building LLM Apps in Java with Jakarta

Shaaf Syed — Sat, 08 Feb 2025 08:12:51 +0000

Java is an amazing language to work with. Millions of developers use it for daily work routines, and many mission-critical applications run on Java today. Whether we talk about banks, stock exchanges, or space, Java is prevalent and a language of choice.

With the advent of Large Language Models(LLM), new opportunities are at play. While Python has been the dominating language runtime for apparent reasons, there is a misconception that creating applications, agents, or other components for LLMs should also be done in Python. Most of the integration in LLMs is achieved by using REST API. Java is not short on anything in that space. System integration has been pretty awesome in Java, with many tools in that space. So why not Java?

LangChain4J! The amazing developers and contributors have provided many goodies for us to infuse LLMs into our apps. Use LangChain4J if you haven't done so yet.

I had the opportunity to speak with A N M Bazlur about this topic at the JChampionsConf last week.

The source code and step-by-step guide is available here on github.
And the speakerdeck.

Embracing the Future of Application Modernization with KAI

Shaaf Syed — Mon, 29 Jul 2024 16:16:20 +0000

Konveyor’s main strength lies in its comprehensive approach to migration and modernization. At the core of Konveyor’s functionality is its powerful analysis engine. This engine performs static source code analysis, identifying anti-patterns and issues that might hinder the application’s operation on a target platform. Utilizing community standards like the Language Server Protocol, Konveyor's analysis engine uses rules designed to aid in various migration scenarios. Users can also create custom rules to address specific migration needs, enhancing Konveyor's flexibility and adaptability.

Enter Konveyor AI - "KAI"

Konveyor AI, the latest advancement under the Konveyor umbrella, leverages generative AI to further streamline application modernization. The primary goal of Konveyor AI (or Kai) is to automate source code changes, thereby improving the economics of migration and modernization efforts.

Our approach is to use static code analysis to find the areas in source code that need to be transformed. 'kai' will iterate through analysis information and work with LLMs to generate code changes to resolve incidents identified from analysis. This approach does not require fine-tuning of LLMs, we augment a LLMs knowledge via the prompt, similar to approaches with RAG by leveraging external data from inside of Konveyor and from Analysis Rules to aid the LLM in constructing better results. For example, analyzer-lsp Rules such as these (Java EE to Quarkus rulesets) are leveraged to aid guiding a LLM to update a legacy Java EE application to Quarkus

There is an awesome blog post by John Matthews one of the Lead engineers in the project explaining "Kai" in depth.

BYO Large Language Model

One of the standout features of Kai is its model-agnostic approach. Unlike other solutions, Kai doesn’t bundle any specific large language model (LLM). Instead, it extends Konveyor to interact with various LLMs, providing the flexibility to use the best-suited model for each specific migration context. This approach ensures that organizations can optimize their migration strategies without being locked into a single technology.

Practical usecase: From Java EE to Quarkus

The short demonstration shows how Konveyor AI facilitates migrations from legacy frameworks like Java EE to modern solutions like Quarkus. The process begins with a static code analysis using the Konveyor CLI, which identifies migration issues within the codebase. Once the analysis is complete, Konveyor AI steps in to generate patches for the identified issues, leveraging LLMs to suggest precise code changes.

For instance, outdated Java EE annotations are seamlessly replaced with their modern Jakarta EE counterparts, and JMS-based message-driven beans were converted to JakartaEE annotations, and legacy technology like EJBs turned into REST end points. These changes can be validated by a developer within an integrated development environment (IDE), showcasing how Konveyor AI integrates into existing developer workflows. Konveyor AI does this by using KAI extension.

For a detailed demo and presentation watch this episode of OpenShift commons where Ramón and I go through the details.

Why should I use Konveyor AI's or how? the power of "Kai" lies in its ability to automate repetitive migration tasks, leveraging accumulated knowledge from previous migrations. By focusing on code transformation rather than architectural changes, Kai provides a robust tool for modernizing applications efficiently. It empowers developers to make informed decisions, enabling smoother transitions to modern frameworks and cloud-native environments.

To give the latest build a try head out the to instructions here.

Get involved in the Konveyor community through their mailing lists, Slack channels, and regular meetings.

Java monitoring: Exploring Cryostat 2.4 features on OpenShift

Shaaf Syed — Mon, 18 Dec 2023 21:38:37 +0000

Orignally posted at Red Hat Developers

Red Hat's latest build of Cryostat 2.4, designed specifically for the Red Hat OpenShift Container Platform, brings a wealth of features and enhancements that cater to various monitoring needs for Java applications.

At its core, Cryostat 2.4 excels in comprehensive Java Flight Recorder (JFR) data management. Users can effortlessly start, stop, retrieve, archive, import, and export JFR data, all through an intuitive web console or an accessible HTTP API. This enhances the ease with which developers can handle JVM performance data. Moreover, Cryostat 2.4 provides flexibility in terms of data storage and analysis. Users can store and analyze JFR data directly on their Red Hat OpenShift or export it to external monitoring applications for a deeper dive into the data.

ARM (aarch64)

A significant enhancement in Cryostat 2.4 is its support for Red Hat OpenShift Container Platform 4.11 and later versions, particularly for the ARM64 (aarch64) architecture. This broadens its applicability across various platforms, making it a versatile tool in diverse environments, e.g., edge deployments.

Smart triggering and HTTP API

Another notable feature is the introduction of dynamic JFR recording with MBean custom triggers. The Cryostat agent is equipped with smart triggers that continuously monitor MBean counter values such as runtime, memory, thread, and operating system metrics. Users are able to set custom trigger conditions, thereby adding a layer of precision to JVM monitoring.

Further enhancing its functionality, Cryostat 2.4 introduces an improved HTTP API provided by the Cryostat agent. This serves as an alternative to an application’s JMX port, allowing users to fully utilize Cryostat's features without the need for JMX port exposure in target applications. This is particularly beneficial for enhancing security and simplifying configurations.

JAR distribution

Cryostat 2.4 also offers flexibility in agent deployment. It provides two types of agent JAR file distributions—an all-in-one "shaded" JAR file that includes all dependencies, and a standard JAR file containing only the agent code. This choice caters to different user requirements and helps manage potential dependency conflicts more effectively.

Topology dashboard view

Additionally, Cryostat 2.4 brings new features and fixes to enhance user experience. The Topology and Dashboard views in the Cryostat web console now display additional information about target JVMs, such as operating system name, memory statistics, class path, library paths, input arguments, and system properties. The introduction of a parameter to restart flight recordings offers more control over recording management, addressing a common user pain point.

Significant issues from previous versions have also been addressed. Automated rule-triggering issues in discovered JVM targets have been resolved, with Cryostat performing regular rechecks and reattempts at rule triggering. This ensures a more reliable connection with JVMs, improving consistency and predictability. The agent registration protocol has also seen improvements, resolving issues related to agent registration with the Cryostat server and ensuring a smoother, more reliable process.

Cryostat 2.4 is a testament to Red Hat's commitment to providing robust and innovative solutions for modern containerized applications. With its enhanced features, improved user experience, and greater flexibility, Cryostat 2.4 is poised to be a pivotal tool in JVM monitoring, offering a sophisticated and user-friendly approach to performance monitoring in containerized environments.

How to use Cryostat for your Java workloads

You can install the Red Hat build of Cryostat using our OpenShift operator, available in Red Hat OpenShift's Operator Hub.
For non-production usage, you can also try our Helm chart, included as part of OpenShift’s Helm chart repository.
You can also try Red Hat build of Cryostat here.

Get support for Java

Support for Cryostat, OpenJDK, and Eclipse Temurin is available to Red Hat customers through a subscription to Red Hat Runtimes, Red Hat Enterprise Linux, and Red Hat OpenShift. Contact your local Red Hat representative or Red Hat sales for more details. You can expect support for Java and other runtimes as described under the Red Hat Product Update and Support Lifecycle.

Resources

Whats new for developers in JDK 21

Shaaf Syed — Thu, 21 Sep 2023 08:04:53 +0000

In an exciting development for Java developers, this September 19th marked the release of JDK 21. This release contains many new capabilities that benefit the Java ecosystem, including virtual threads, record patterns, and sequenced collections. There are also some interesting features in the preview for JDK 21, such as string templates, scoped values, and structured concurrency. This article highlights six new features in this release.

Virtual threads

Java's traditional threading model can quickly become an expensive operation if the application creates more threads than the operating system (OS) can handle. Also, in cases where the thread lifecycle is not long, the cost of creating a thread is high.

Enter virtual threads, which solve this problem by mapping Java threads to carrier threads that manage (i.e., mount/unmount) thread operations to a carrier thread. In contrast, the carrier thread works with the OS thread. It is an abstraction that gives more flexibility and control for developers. See Figure 1.

Figure 1: The virtual threading model in JDK 21.

The following is an example of virtual threads and a good contrast to OS/platform threads. The program uses the ExecutorService to create 10,000 tasks and waits for all of them to be completed. Behind the scenes, the JDK will run this on a limited number of carrier and OS threads, providing you with the durability to write concurrent code with ease.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        });
    });
}  // executor.close() is called implicitly, and waits

Structured concurrency (Preview)

Structured concurrency is closely tied to virtual threads, and it aims to eliminate common risks such as cancellation, shutdown, thread leaks, etc., by providing an API that enhances the developer experience. If a task splits into concurrent subtasks, then they should all return to the same place, i.e., the task's code block.

In Figure 2, findUser and fetchOrder both need to execute to get the data from different services and then use that data to compose results and send it back in a response to the consumer. Normally, these tasks could be done concurrently and could be error prone if findUser didn't return; fetchOrder would need to wait for it to complete, and then finally execute the Join operations.

Figure 2: Structured concurrency example.

Furthermore, the lifetime of the subtasks should not be more than the parent itself. Imagine a task operation that would compose results of multiple fast-running I/O operations concurrently if each operation is executed in a thread. The structured concurrency model brings thread programming closer to the ease of single-threaded code style by leveraging the virtual threads API and the StructuredTaskScope.

Response handle() throws ExecutionException, InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        Supplier<String>  user  = scope.fork(() -> findUser());
        Supplier<Integer> order = scope.fork(() -> fetchOrder());

        scope.join()            // Join both subtasks
             .throwIfFailed();  // ... and propagate errors

        // Here, both subtasks have succeeded, so compose their results
        return new Response(user.get(), order.get());
    }
}

Sequenced collections

In JDK 21, a new set of collection interfaces are introduced to enhance the experience of using collections (Figure 3). For example, if one needs to get a reverse order of elements from a collection, depending on which collection is in use, it can be tedious. There can be inconsistencies retrieving the encounter order depending on which collection is being used; for example, SortedSet implements one, but HashSet doesn't, making it cumbersome to achieve this on different data sets.

Figure 3: Sequenced Collections.

To fix this, the SequencedCollection interface aids the encounter order by adding a reverse method as well as the ability to get the first and the last elements. Furthermore, there are also SequencedMap and SequencedSet interfaces.

interface SequencedCollection<E> extends Collection<E> {
    // new method
    SequencedCollection<E> reversed();
    // methods promoted from Deque
    void addFirst(E);
    void addLast(E);
    E getFirst();
    E getLast();
    E removeFirst();
    E removeLast();
}

So now, not only is it possible to get the encounter order, but you can also remove and add the first and last elements.

Record patterns

Records were introduced as a preview in Java 14, which also gave us Java enums. record is another special type in Java, and its purpose is to ease the process of developing classes that act as data carriers only.

In JDK 21, record patterns and type patterns can be nested to enable a declarative and composable form of data navigation and processing.

// To create a record:

Public record Todo(String title, boolean completed){}

// To create an Object:

Todo t = new Todo(“Learn Java 21”, false);

Before JDK 21, the entire record would need to be deconstructed to retrieve accessors.. However, now it is much more simplified to get the values. For example:

static void printTodo(Object obj) {
    if (obj instanceof Todo(String title, boolean completed)) {
            System.out.print(title);
System.out.print(completed);
    }
}

The other advantage of record patterns is also nested records and accessing them. An example from the JEP definition itself shows the ability to get to the Point values, which are part of ColoredPoint, which is nested in a Rectangle. This makes it way more useful than before, when all the records needed to be deconstructed every time.

String templates

String templates are a preview feature in JDK 21. However, it attempts to bring more reliability and better experience to String manipulation to avoid common pitfalls that can sometimes lead to undesirable results, such as injections. Now you can write template expressions and render them out in a String.

// As of Java 21
String name = "Shaaf"
String greeting = "Hello \{name}";
System.out.println(greeting);

In this case, the second line is the expression, and upon invoking, it should render Hello Shaaf. Furthermore, in cases where there is a chance of illegal Strings for example, SQL statements or HTML that can cause security issues—the template rules only allow escaped quotes and no illegal entities in HTML documents.

More JEPs in JDK 21

Other JEPs that I did not cover in this article but in another post

JEP 439: Generational ZGC
JEP 441: Pattern Matching for switch
JEP 442: Foreign Function & Memory API (Third Preview)
JEP 443: Unnamed Patterns and Variables (Preview)
JEP 445: Unnamed Classes and Instance Main Methods (Preview)
JEP 448: Vector API (Sixth Incubator)
JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
JEP 451: Prepare to Disallow the Dynamic Loading of Agents
JEP 452: Key Encapsulation Mechanism API

Get support for Java

Support for OpenJDK and Eclipse Temurin is available to Red Hat customers through a subscription to Red Hat Runtimes, Red Hat Enterprise Linux, and Red Hat OpenShift. Contact your local Red Hat representative or Red Hat sales for more details. You can expect support for Java and other runtimes as described under the Red Hat Product Update and Support Lifecycle.

Resources

Keycloak Operator for Kubernetes - a Basic Tutorial

Shaaf Syed — Sat, 09 Sep 2023 05:18:41 +0000

The Keycloak team announced that they were going to move to a new Operator framework that will effictevely manage Keycloak installatons on a Kubernetes cluster.
So what is an Operator in the Kubernetes context. Simplyfying it a bit here... Its basically a component that takes over the operational aspects of your application. So rather then managing all of the lifecycle and state in scripts and in our minds in someways is coded into an operator. For us Keycloak Operator does exactly that and in this blog I will cover how to setup a very simple Keycloak installation and get ready for development. If you are interested in knowing more about Operators you will likely find some good info here.

If you arent familiar with Keycloak; its an opensource identity and access management software. Current version is 22, its used alot already in the wild. It provides single sign on capabitlity with OAuth/OIDC, AD, LDAP and SAML v2 as well. If you aren't very familiar with Keycloak, I have also written a small self-paced Keycloak tutorial that goes through all the basics and some advance configs too.

Let's get cracking on installing a basic keycloak instance backed by a PostgreSQL database.

So heres the plan

Install Operator on OpenShift cluster (a distribution of Kubernetes by Red Hat)
Install database for the Keycloak backend.
Create SSL certificate for use with keycloak backend.
Install the first Keycloak instance.
Importing a realm

Installing the Operator

To install the Keycloak operator I am choosing to install it via the webconsole which is an easy way to do it. Its also possible to do it via CLI.

Simply search for keycloak and press install. e.g.

Once you press install the installer will ask which namespace you would like to install to. In my case it the rhbk.

This could take a couple of seconds or minutes depending on your cluster.

Installing the database

For the Keycloak server to store its state and data it should have a database. For this I will use Crunchy.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql-db
spec:
  serviceName: postgresql-db-service
  selector:
    matchLabels:
      app: postgresql-db
  replicas: 1
  template:
    metadata:
      labels:
        app: postgresql-db
    spec:
      containers:
        - name: postgresql-db
          image: postgres:latest
          volumeMounts:
            - mountPath: /data
              name: cache-volume
          env:
            - name: POSTGRES_PASSWORD
              value: testpassword
            - name: PGDATA
              value: /data/pgdata
            - name: POSTGRES_DB
              value: keycloak
      volumes:
        - name: cache-volume
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: postgres-db
spec:
  selector:
    app: postgresql-db
  type: LoadBalancer
  ports:
  - port: 5432
    targetPort: 5432

Create SSL certificate for use with keycloak backend.

Okay time to create a self-signed certificate, incase it was production assuming that would be via a certificate autority instead. But here since I am just testing this out we an just use the self-signed certificate. On a linux machine I can create a self-signed certificate like this where keycloak.rhbk.apps.green.demoshift.com is the address to my keyclaok instance and O is Test demoshift. it could be anything you want to denote here in my case its a test Org.

openssl req -subj '/CN=keycloak.rhbk.apps.green.demoshift.com/O=Test demoshift./C=US' -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem

Generating a 2048 bit RSA private key
.....................+++++
.....................+++++
writing new private key to 'key.pem'

Lets load this certificate into our Kubernetes environment by usng the following command. Make sure the path for the cert is correct, in my case I am in the same dir as my cert.

kubectl create secret tls example-tls-secret --cert certificate.pem --key key.pem

Also a good practise is to load the database password as a secret rather then it littering around different yaml files.

kubectl create secret generic keycloak-db-secret \ 
            --from-literal=username=postgres \
            --from-literal=password=testpassword

Install the first Keycloak instance

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  instances: 1
  db:
    vendor: postgres
    host: postgres-db
    usernameSecret:
      name: keycloak-db-secret
      key: username
    passwordSecret:
      name: keycloak-db-secret
      key: password
  http:
    tlsSecret: example-tls-secret
  hostname:
    hostname: keycloak.rhbk.apps.green.demoshift.com

Now if we go back to the webconsole you should be able to see.

1. Keycloak operator pod
2. PG database pod
3. Keycloak server pod.

OpenShift has this nice feature that you can see the route once you click your application. also visible in the image below. Head over to your instance and login.

To login obviously one needs the admin password which in this case has been autogenerated by the operator. Lets get that by running the following command.

kubectl get secret example-kc-initial-admin -o jsonpath='{.data.password}' | base64 --decode

Assuming we have the password, lets go back to the route and click on Adminstration console. Username is admin and password should be what we retrieved from the command above.

Importing a realm

At this moment we only have the master realm. Typically one should leave the master realm intact without much changes. The logic behind that would be not to lock ourselves out. How about we import a realm. And here the power of Operator comes into play. We will create a RealmImportCR and that will add a new realm to Keycloak. Imagine if the Keycloak pod goes down at some point, the operator will ensure that its brought back to the same state it was and where is that state going to be? in the CRs and the database.

Okay lets test this out further, how about adding a new realm via the KCImportRealmCR

Let's go back to the Operator view

Click on KeycloakRealmImport -> Create instance

I had a realm json file. And obviously operators and most of the stuff in K8s expects yaml so I had to make a conversion. I used the following yq for conversion. There are also online tools available, but given the sensitive nature of realms I wouldnt suggest using a random online tool to convert to yaml.

So here is the resultant CR

Load the yaml and press create

It can take a couple of seconds to that it will come up. As soon as we create the CR, the Keycloak Operator will pick it up and add it to the running Keycloak instance. If you log back into the admin console it should look like this.

And if we explore further and look into the clients there is a backend-service. Its a Client config for a Quarkus based REST service written in Java. Thats for another post. There is alot more that can be done with Operators.

If you are looking for more in depth details the Keycloak docs is a great resource. If you are looking to explore more and try this installation you can also use the following Keycloak tutorial

More to come on Keycloak in later posts.

How-to configure your first user with OpenShift IDP - htpasswd

Shaaf Syed — Mon, 21 Aug 2023 13:22:40 +0000

There are multiple options to configure OpenShift integration with an IDP. Usually one would use something like an LDAP, AD (Active Directory) for use in a production cluster or a corporate environment. This guide is a basic how-to in configuring using the htpasswd file which is one of the IDP integration options in Openshift 4.x.

htpasswd is a tool used to create and update the flat-files used to store usernames and password for basic authentication of HTTP users. These flat-files are commonly used by the Apache HTTP Server, as well as some other server software, to provide password protection for web content.

Okay lets do this.

You want to run the following command on your linux/unix box. This command should create a new .htpasswd file (because of -c), use bcrypt encryption for the password (because of -B), and take the password directly from the command line (because of -b).

htpasswd -c -B -b myhttpasswdfile.htpasswd mydesireduser mypassword

httpasswd - the cli to generate the file
-c - This option is used to create a new password file. If the specified password file already exists, using this option will overwrite it. Be cautious when using -c to ensure you don't unintentionally erase existing files.
B - This option tells htpasswd to use the bcrypt encryption for the password. Bcrypt is a strong method for hashing passwords, and it's recommended over the older methods like MD5 or SHA because of its resistance to brute-force attacks.
b - This option allows you to specify the password on the command line rather than being prompted for it. This can be helpful in scripting but is considered less secure because the password can be viewed in the command history or by other users using commands like ps on UNIX-based systems.

Okay now that we have a simple htpasswd file with one user. Lets add it to OpenShift.

Login to your OpenShift Console and hit this URL:\
<Your OpenShift Console>/k8s/cluster/config.openshift.io~v1~OAuth/cluster

Or Goto Adminsitration > Cluster Settings > Tab "Configuration" and Select OAuth. like the following screenshot

Okay perfect once at the OAuth Config screen, click add under Identity providers, you should be able to see the dropdown list as follows. Select htpasswd from it.

And then lets just browse to the htpasswd file created and press add. This will take a couple of secs and should be ready as the CR is submitted. What OpenShift will do in the backgroud is create the htpasswd OAuth provider and it will sync to all the master nodes under /etc/origin/master/.

You should now be able to login via oc login or via the OpenShift console.
Incase of any issues check the tips here for diagnostics or docs

Processing images in Java with OpenCV and Quarkus

Shaaf Syed — Wed, 13 Apr 2022 10:42:36 +0000

If you are into Computer vision, you probably are familiar with OpenCV. Its an amazing library that has almost everything one needs to do 2D and 3D processing and much more. Gesture recognition, face detection, Motion tracking, think of anything related to image processing and OpenCV can be your goto. Its based on the BSD license, so you can just download it and start using it.

OpenCV is written in C, and there are nice Java bindings for it too. If you are a Java developer like me and dont want to get into all the loading and building native bindings etc., then read on. In this article I will show how you can use OpenCV with the popular new framework Quarkus, without worrying about installing libraries or reloading the entire app.

Quarkus is a container first, Kubernetes native framework that was started by Red Hat and it focuses purely on Developer Joy. The fun part IMHO is the live coding feature, which we will see in our app. I dont really need to keep on building and reloading my app, even though it uses JNI, and I can just simply keep chugging along and coding with ease. I just love this! It makes life simpler.

Setting up

Assuming you have a working Java environment. that would mean a Java runtime, a Maven or Gradle system for build. You might be thinking that you need to download the OpenCV libraries for JNI to work etc.. well guess what you dont need to! Quarkus OpenCV extension will take care of it. Quarkus extensions are a way of enabling more functionality to the core Quarkus framework. Quarkiverse is the hub that holds all extensions. So if you are e.g. looking for a nice framework to generate docs, or fuzzy search with hibernate-search or Amazon services integration etc etc.. Well take a look for yourself here

Okay so we are going to use the Quarkus-OpenCV extension.
To do this we will first create the a simple Java cli project from code.quarkus.io

There's a couple of ways to get started. One could just head over to code.quarkus.io and create a project there or run local maven command or use the Quarkus cli. I am going to take the approach that I am most well known too. Lets start with maven.

<1> mvn io.quarkus.platform:quarkus-maven-plugin:2.7.5.Final:create \
                    -DprojectGroupId=org.acme \
                    -DprojectArtifactId=getting-started \
                    -Dextensions="resteasy"

<2> cd getting-started                    

<3> ./mvnw quarkus:add-extension -Dextensions="io.quarkiverse.opencv:quarkus-opencv"

<1> - here we download the starter project from code.quarkus.io. The project name is getting-started.
<2> - I am changing directory into the newly created project.
<3> - And finally I am also adding the OpenCV extension from Quarkiverse to our project.

Perfect now we should have a project to get to work. Lets open it up in an IDE. Then

Lets check the pom.xml that it has the right dependencies. If you are following this along, make sure the following is the list of dependencies in the pom.xml.

  <dependencies>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-arc</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkiverse.opencv</groupId>
      <artifactId>quarkus-opencv</artifactId>
      <version>LATEST</version>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-junit5</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>rest-assured</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>

Next, since I have removed the rest-easy dependency, I shall also remove the REST end point. in org.acme.GreetingResource.java and the Tests thereof.

Perfect so now we have a clean project to get started. Here

Create the CLI Main

Quarkus provides the option to create command line apps, and this is so kool, since you can also compile these into native. We are just going to make simple app for demo purpose in this blog. But if you are looking into creating some serious nirvana of cli apps take a look at this guide at quarkus.io using picocli or JBang

In my app I try to keep it simple. Lets create the barebones QMain Class.

package org.acme;

import io.quarkus.runtime.QuarkusApplication;
import io.quarkus.runtime.annotations.QuarkusMain;

@QuarkusMain
public class QMain implements QuarkusApplication {

    @Override
    public int run(String... args) throws Exception {
        // TODO Auto-generated method stub
        return 0;
    }
}

I am now going to run this app in a terminal. And the command should initiate a livecoding session as the app is started.

Initiate Live Coding

~/demos/getting-started mvn quarkus:dev

So what's live coding? Well just keep on coding, dont worry about restarting your app, or adding new dependencies and config or rebuidling.. etc. You just dont need to restart the app everytime! (*almost)

I am going to leave the terminal running and get back to coding in QMain.

I am going to add two class level properties, one to read an image from and the second to save an image to. Quarkus via the Microprofile APIs provdies the @ConfigProperty. This enables me to inject config properties into my app. Here is how I do it.

    // Set these in your application.properties
    @ConfigProperty(name = "cli.sourceImagePath")
    String testImage;

    // Set these in your application.properties
    @ConfigProperty(name = "cli.targetImagePath")
    String targetImage;

And in my application.properties I add the path to these files

cli.sourceImagePath=images/testImage.jpg
cli.targetImagePath=images/testImageDetected-output.jpg

One is the cli.sourceImagePath, this has to be present in order for it to be processed. And the cli.targetImagePath doesnt need to be present since I will save the image there. In my case I have added the images into the root of my project, hence the path images/

Load and Save images

Now back to QMain. I am going to add the save and load methods for these paths.

    /**
     * Loading the image
     */
    public Mat loadImage(String imagePath) {
        Imgcodecs imageCodecs = new Imgcodecs();
        return imageCodecs.imread(imagePath);
    }



    /**
     * Save the image to the targetPath
     */
    public void saveImage(Mat imageMatrix, String targetPath) {
        Imgcodecs imgcodecs = new Imgcodecs();
        imgcodecs.imwrite(targetPath, imageMatrix);
    }

Mat has two parts the Image headers, and the data matrix.The header is constant but the size of the matrix will depend on the image. Mat is used to load the images from a path and Mat forms the basic construct for us to perform operations on the image.

Defining the Filter Interface

And to make multiple Filters to process images, I am going to define an interface that takes Mat as a source, processes it and then returns Mat. This way I can apply multiple filters on an image before I save them.

package org.acme;

import org.opencv.core.Mat;

public interface Filter {

    public Mat process(Mat src);

}

Connecting the dots

And finally lets try to connect the structure by adding the methods calls to the QMain's run method.And spark some joy!

    @Override
    public int run(String... args) throws Exception {
        Mat m = loadImage(testImage);

        saveImage(m, targetImage);
        return 0;
    }

Simple, all I do above is load the image and save the image. No processing yet. How do you test that. Remember the terminal where we ran mvn quarkus:dev

Press space on that. And the program will just continue executing. How kool is that! No need to rebuild, all the config, the new classes everything just worked. Thats what sparks the Developer Joy! , with Quarkus!

Checkout the logs. It states File change detected for the application.properties, more over It also lists the Classes that have changed.

So what just happened?
Quarkus runtime just executed the cli app. which means that if I goto cli.targetImagePath I should see an image created there. At this point it will look the same as the source image, since I havent processed anything on it yet. Guess what? thats exactly whatI plan to do now.

Moving on, the image I am using today is provided by Shuttergames on Unsplash

Gaussian Blur

The first filter I create is a GaussianBlurfilter. Its a low-pass filter meaning that it attenuates higher frequency signals. The overall visual effect would be a smooth blur.

package org.acme;



import org.opencv.core.Mat;
import org.opencv.core.Size;
import org.opencv.imgproc.Imgproc;

public class GaussianBlur implements Filter {

    @Override
    public Mat process(Mat src) {

        if(src != null) {
            int MAX_KERNEL_LENGTH = 45;
            Mat dst = new Mat();
            for (int i = 1; i < MAX_KERNEL_LENGTH; i = i + 2) {
                Imgproc.GaussianBlur(src, dst, new Size(i, i), 0, 0);
            }
            return dst;
        }

        else throw new IllegalArgumentException("Looking for Mat nothing found!, try passing org.opencv.core.Mat to process");
    }
}

Above we define a kernel size. Kernel is a matrix that defines how an anchored pixel and its surrounding pixels are changed based on the function provided.

The kernels will define the size of the convolution, the weights, and an anchor point positioned at the center. The process method takes a Mat object applies the GuassianBlur filter with the Kernel size, and finally returns the Mat object back.

RGB2Grey

Adding the following to the run mehtod in QMain so I can call my Filter.

    @Override
    public int run(String... args) throws Exception {
        Mat m = loadImage(testImage);

        m = new GaussianBlur().process(m);

        saveImage(m, targetImage);
        return 0;
    }

Perfect, now if I press the space bar again on the terminal, its should execute all my changes. Resulting in the blur as shown below. The blur is smooth, almost like if its been overlayed with a lense.

Next, lets make another filter. this time how about I make the image Grey. To do that OpenCV already provides a simple function. Again I am using the Fitler interface for this hence passing a Mat and recieving one back.

package org.acme;

import org.opencv.core.Mat;
import org.opencv.imgproc.Imgproc;



public class RGB2Grey implements Filter{

    @Override
    public Mat process(Mat src) {
        if(src != null) {
            Mat dst = src;
            Imgproc.cvtColor(src, dst, Imgproc.COLOR_RGB2GRAY);
            return dst;
        }
        else throw new IllegalArgumentException("Looking for Mat nothing found!, try passing org.opencv.core.Mat to process");
    }
}

Above code using ImgProc that provides this operation to move all pixels from RGB to Grey.

 m = new RGB2Grey().process(m);

Adding the above to my run method and pressing the space bar again in the terminal should execute all my cahnges again. and Vola! I have a Grey tone image.

Hope you enjoyed this run through on how to use Quarkus and OpenCV together. For more examples take a look at the github repo with code examples.

SQL cache stores and more in Data Grid 8.3

Shaaf Syed — Thu, 24 Feb 2022 15:42:03 +0000

Red Hat Data Grid is a distributed, cloud-based datastore offering very fast response times as an in-memory database. The latest version, Data Grid 8.3, features cross-site replication with more observability and two new types of SQL cache store for scaling applications with large datasets. This version also brings improved security, support for Helm charts, and a better command-line interface (CLI).

This article is an overview of new features and enhancements in this latest version of Red Hat Data Grid.

Cross-site replication with more observability

With the latest Data Grid release, you can track cross-site replication operations for each of the backup locations and their caches, including response times and the number of RELAY messages exchanged, as shown in Figure 1.

Figure 1. Cross-site replication involves messages at many different levels.

We have also enabled access to the data via the CLI, the REST API, and Java Management Extensions (JMX) to offer a better user experience to cluster operators. Cross-site replication is also more transparent and observable due to dedicated, operator-managed pods for routing cross-site replication requests.

Data Grid operators can also configure the number of relay nodes for cross-site replication. This flexibility enhances the cache's scalability and performance over multiple sites.

Finally, security is of paramount importance for a cross-site cluster, so we have enabled TLS security for router-based cross-site replication. (Scroll down for more about security enhancements in a later section.)

Scaling with SQL cache stores

What do you do if you have a lot of data in a database and want to load the data into the cache? Database schemas can be complex and users might want to define how that data is queried through operations such as SELECT, INSERT, and so on. Perhaps you would also like to support write-through and write-back operations. All of this makes for a complex scenario.

In this release, we have added two types of SQL cache store:

Table cache store: Loads all data from a single table. Only the table name is required.
Query cache store: Loads data based on SQL queries.

Useful things you can do with the new SQL cache stores include the following:

Pre-load data from an existing database.
Expose cache data with a user-defined schema.
Allow read and write operations.
Configure the cache store as read-only, and act as a cache loader.
Configure the cache store to load values on startup.
Use the cache store with composite keys and values through the protocol buffers (protobuf) schema.
With the query cache store, use arbitrary select, select all, delete, delete all, and upsert operations.

To set up a cache store, you simply need to drop the database drivers into the server, which can be done with the Operator custom resource (CR) on Red Hat OpenShift. After that, users should be able to create SQL cache stores via YAML, JSON, or XML—also a new configuration feature. An example using Infinispan and the Quarkus Java framework is available on GitHub.

More security enhancements

Data Grid now provides full support for TLS version 1.3 with OpenSSL native acceleration. We have also increased the flexibility and convenience of security in Data Grid 8.3.

Multiple realms

You can combine multiple security realms into a single realm. When authenticating users, Data Grid Server checks each security realm in turn until it finds one that can perform the authentication.

The following example security realm includes an LDAP realm and a property realm, along with the distributed-realm element:

<security-realms>
   <security-realm name="my-distributed-realm">
      <ldap-realm>
         <!-- LDAP realm configuration. -->
      </ldap-realm>
      <properties-realm>
         <!-- Property realm configuration. -->
      </properties-realm>
      <distributed-realm/>
   </security-realm>
</security-realms>

Multiple endpoints

Users can now also configure multiple endpoints and define separate security realms for them. This enhancement enables more flexible and secure use.

The following example contains two different endpoint configurations. One endpoint binds to a public socket, uses an application security realm, and disables administrative features. Another endpoint binds to a private socket, uses a management security realm, and enables administrative features:

<endpoints>
  <endpoint socket-binding="public"
            security-realm="application"
            admin="false">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
  <endpoint socket-binding="private"
            security-realm="management">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
</endpoints>

PEM files

Users can now add PEM files directly to their Data Grid Server configuration and use them as trust stores and keystores in a TLS server identity.

Note: See the Data Grid Security Guide and Distributed security realms to learn more about new security features in Data Grid 8.3.

Deploy Data Grid with Helm charts

Developers who use Helm charts for application deployment can now use this convenient mechanism to install Data Grid. You can use charts to deploy Data Grid instances, configure clusters, add authentication and authorization, add network access via routes and node ports, enable load balancers, and more, using the Data Grid portal (Figure 2) or the CLI.

Figure 2. Helm charts can be invoked through the Data Grid graphical interface.

Note: Using Helm charts is intended for sites where the Data Grid Operator is not available and operators must configure, deploy, and manage the cluster manually.

CLI improvements

Data Grid 8.3 has a few updates for developers who prefer working on the command line. For one, you can enable and disable rebalancing of the cluster, track and extract more details about cross-site replication relay nodes, and manage cache availability. Additionally, if you use the general oc OpenShift command, you can now also install the Infinispan extension and use it with oc, as shown in Figure 3.

Figure 3. You can control a Data Grid cluster from the command line.

Usability improvements

We've made a few more improvements to increase the usability of Data Grid in this release:

Data Grid 8.3 has full support for Java 17 for embedded and remote caches.
You can automatically migrate any file-store configuration during the upgrade to Data Grid 8.3.
You can now delete entries with the Ickle programming language:
query.create("DELETE FROM books WHERE page_count > 500").executeStatement();
Copy snippet
Hot Rod migration is simpler when upgrading clusters of server nodes between versions and handles configuration changes transparently.

Get started with Data Grid 8.3

Ready to dive in and try out Data Grid 8.3? These resources will get you started:

Zip distributions are available through the Certified Service Provider (CSP) program.
Container distributions and Operators are available in the Red Hat Container Catalog.
Product documentation is available on the Red Hat customer portal, including a migration guide to help you migrate your existing Data Grid deployments to 8.0.

Visit the Red Hat Data Grid product page to learn more about this technology.

What's new for developers in Java 18

Shaaf Syed — Thu, 27 Jan 2022 10:33:46 +0000

In exciting news for Java developers, Java 18 forked off from the main line at the end of last year and has entered Rampdown Phase Two. This article highlights some of the features that developers can look for in the upcoming Java 18 release, including the new simple web server module, a more sophisticated way to annotate your Javadocs, and the –finalization=disabled option, which lets you test how a Java application will behave when finalization is removed in a future release. See the end of the article for where to download Java 18 in early access builds.

Java's new simple web server

Java 18 will provide a minimally functional web server in the jdk.httpserver module. It has an API for access, as well as a binary in the bin directory in case you want to run the server from the command line.

The command to run the web server can be as simple as:

$ jwebserver -b 0.0.0.0 -p 8000

Note:** For more command-line options and details about the jdk.httpserver module, see the JEP 408 documentation.

If you are wondering whether you can implement a full-blown production web server using the simple web server APIs, the answer is no. The web server is definitely not intended for that use. For one thing, it communicates over HTTP/1.1 and doesn't support PUT requests, so it doesn't support dynamic content. The web server is recommended for prototyping, testing, and debugging. An example code snippet with comments follows:

import java.net.InetSocketAddress;
import java.nio.file.Path;
import com.sun.net.httpserver.SimpleFileServer;
import static com.sun.net.httpserver.SimpleFileServer.OutputLevel;

public class App {
public static void main( String[] args ){
    // Create a simple file server, given the socket address, path and output level
    var server = SimpleFileServer.createFileServer(new InetSocketAddress(8000),             Path.of("/home/java"), OutputLevel.VERBOSE);

    // Starting the server
    server.start();

    // A friendly message to get started.
    System.out.println( "We are getting started.. Hello World!" );
  }
}

Code snippets in Java API documentation

Prior to Java 18, developers mostly inserted code samples in Javadoc comments using the @code annotation. That technique is somewhat limited and requires workarounds. For instance, it has always been difficult to validate what's inside the code fragment, implement syntax highlighting, and insert links or escape characters.

As a new approach, JEP 413 proposes using the @snippet tag. As noted in the JEP, the tag "can be used to declare both inline snippets, where the code fragment is included within the tag itself, and external snippets, where the code fragment is read from a separate source file."

Here is an example of an inline snippet:

/**
* The following code shows how to use {@code Optional.isPresent}:
* {@snippet :
* if (v.isPresent()) {
*     System.out.println("v: " + v.get());
* }
* }
*/

The code lies between curly braces, where the opening brace is followed by the @snippet tag. The Javadoc utility now also includes options to specify links, highlight code, and more. See JEP 413 for more details.

UTF-8 character set by default

In prior releases, the default character set was determined when the Java runtime started, and depended on the user's locale and default encoding. Thus, on Windows the charset was windows-1252, whereas on macOS it was UTF-8 except in the POSIX C locale. With Java 18, UTF-8 will be the default for all operating systems.

You can change the default charset by setting the file.encoding to COMPAT; for instance, by running java -Dfile.encoding=COMPAT. This setting reverts to the algorithm in Java 17.

Prepare now for the removal of finalize()

If you have developed Java applications, you are probably familiar with the finalize() method. Since Java 9, the recommendation has been to not use finalize(), but instead to use a try-with-resources statement or the new Cleaner APIs. JEP 421 helps developers prepare for the eventual removal of finalization. You can run an application with the –finalization=disabled option to see how it will behave without the finalize() method. It's great to see this evolution. As a developer, it is also an opportunity to take a closer look at your application's behavior.

**Note: **A recent Inside Java podcast episode discusses issues with finalization and what to expect in Java 18. See the documentation for JEP 421 for more details.

Preview features in Java 18

Some of the features that were included in the development phase of Java 18 are still in preview. These include the Vector API (JEP 417), which Gunnar Morling discusses in this DevNation Tech Talk. The foreign function and memory API (JEP 419) and pattern matching for switch (JEP 420) also remain in preview.

Where to download Java 18

To give Java 18 a try, you can download the early access Eclipse Temurin builds from Eclipse Adoptium. Temurin is the name of the OpenJDK distribution from Adoptium.

If you are using a current version of Java and want to compare the features with Java 18, I would also highly recommend the Java Almanac. It contains a page listing all the new features and changes in Java 18.

Conclusion

This article was a quick look at some of the highlights of Java 18. Keep an eye on the Red Hat Developer OpenJDK page for more Java 18 updates. You can also get started using the Red Hat build of OpenJDK.

Forem: Shaaf Syed

Modernizing Legacy Code with Konveyor AI: From EJB to Kubernetes

Modernizing Legacy Code with Konveyor AI: From EJB to Kubernetes

Beyond Chat: Agents and Memory

1. Agentic Validation

2. Organizational Memory

Get Involved

Nano Agent, Mega Senses: Adding LSP to the 260-Line Coding Agent

Does LSP fits the same architecture?

What this fork adds (in practice)

Examples (prompts that now “make sense”)

Trade-offs worth saying out loud

Links

Java + LLMs: A hands-on guide to building LLM Apps in Java with Jakarta

Embracing the Future of Application Modernization with KAI

Enter Konveyor AI - "KAI"

BYO Large Language Model

Practical usecase: From Java EE to Quarkus

Java monitoring: Exploring Cryostat 2.4 features on OpenShift

ARM (aarch64)

Smart triggering and HTTP API

JAR distribution

Topology dashboard view

How to use Cryostat for your Java workloads

Get support for Java

Resources

Whats new for developers in JDK 21

Virtual threads

Structured concurrency (Preview)

Sequenced collections

Record patterns

String templates

More JEPs in JDK 21

Get support for Java

Resources

Keycloak Operator for Kubernetes - a Basic Tutorial

Installing the Operator

Installing the database

Create SSL certificate for use with keycloak backend.

Install the first Keycloak instance

Importing a realm

How-to configure your first user with OpenShift IDP - htpasswd

Processing images in Java with OpenCV and Quarkus

Setting up

Create the CLI Main

Initiate Live Coding

Load and Save images

Defining the Filter Interface

Connecting the dots

Gaussian Blur

RGB2Grey

SQL cache stores and more in Data Grid 8.3

Cross-site replication with more observability

Scaling with SQL cache stores

More security enhancements

Multiple realms

Multiple endpoints

PEM files

Deploy Data Grid with Helm charts

CLI improvements

Usability improvements

Get started with Data Grid 8.3

Recent Articles

Related Content

What's new for developers in Java 18

Java's new simple web server

Code snippets in Java API documentation

UTF-8 character set by default

Prepare now for the removal of finalize()

Preview features in Java 18

Where to download Java 18

Conclusion