1. Overview

In this tutorial, we’ll shed light on how to convert between ByteBuffer and Byte arrays in Java. Understanding how to convert between these two formats is essential for tasks such as file I/O handling and network communication.

We’ll look at different methods for converting a ByteBuffer to a Byte[] and vice versa, then we’ll discuss when to use each approach.

2. Converting ByteBuffer to Byte Array

In Java, ByteBuffer is a core class from the java.nio package. It’s introduced to handle binary data in an efficient way. This is why it’s widely used in I/O operations.

First, let’s start by exploring how we can extract a Byte array from a ByteBuffer.

2.1. Using ByteBuffer.array()

The simplest and most straightforward option is to use the array() method. Typically, this method returns the byte array that backs the buffer:

@Test
void whenUsingArrayMethod_thenConvertToByteArray() {
    byte[] givenBytes = {1, 6, 3};
    ByteBuffer buffer = ByteBuffer.wrap(givenBytes);
    byte[] bytes = buffer.array();
 
    assertArrayEquals(givenBytes, bytes);
}

An important caveat here is that the array() method only works when the buffer has an accessible backing array. Otherwise, it throws UnsupportedOperationException:

@Test
void givenBufferWithoutBackingArray_whenCallingArray_thenThrowUnsupportedOperationException() {
    ByteBuffer buffer = ByteBuffer.allocateDirect(4);
    assertThrows(UnsupportedOperationException.class, buffer::array);
}

It’s always safer to check whether the buffer has a backing array using the hasArray() method before calling array(). It acts as a guard to prevent UnsupportedOperationException.

Please note also that the array() method throws ReadOnlyBufferException if the buffer is read-only:

@Test
void givenReadOnlyBuffer_whenCallingArray_thenThrowReadOnlyBufferException() {
    ByteBuffer buffer = ByteBuffer.wrap(new byte[] {1, 2, 3});
    ByteBuffer readOnlyBuffer = buffer.asReadOnlyBuffer();
    assertThrows(ReadOnlyBufferException.class, readOnlyBuffer::array);
}

As we can see, the array() method fails with a ReadOnlyBufferException.

2.2. Using ByteBuffer.get()

Alternatively, we can use the get() method. It offers a more robust and flexible approach to extract a Byte array:

@Test
void whenUsingGetMethod_thenConvertToByteArray() {
    byte[] givenBytes = {5, 4, 2};
    ByteBuffer buffer = ByteBuffer.wrap(givenBytes);
    byte[] bytes = new byte[buffer.remaining()];
    buffer.get(bytes);
    assertArrayEquals(givenBytes, bytes);
}

This method creates a new copy of the buffer’s data, which guarantees independence between the buffer and the returned byte array.

Please note that we can specify an offset and a length for more precise control over how data is copied from the buffer:

@Test
void givenByteBuffer_whenUsingGetWithParamsMethod_thenConvertToByteArray() {
    byte[] givenBytes = {5, 4, 2, 7};
    ByteBuffer buffer = ByteBuffer.wrap(givenBytes);
    byte[] bytes = new byte[2];
    buffer.get(bytes, 0, 2);
 
    assertArrayEquals(new byte[] {5, 4}, bytes);
}

Here, the destination array contains only 2 elements, matching the number of copied bytes.

3. Converting Byte Array to ByteBuffer

Now, let’s go down the rabbit hole and see how to create a ByteBuffer from a byte array.

3.1. Using ByteBuffer.wrap()

The most common approach is using the method wrap(). As the name implies, it wraps a given byte array into a buffer:

@Test
void whenUsingWrapMethod_thenConvertToByteBuffer() {
    byte[] givenBytes = {1, 2, 3};
    ByteBuffer buffer = ByteBuffer.wrap(givenBytes);
     
    assertArrayEquals(givenBytes, buffer.array());
}

Notably, this method creates a buffer that directly uses the provided array as its backing storage. So, any change to the buffer will be reflected in the array and vice versa.

ByteBuffer also provides wrap(array, offset, length). However, instead of creating a new array starting at the offset, it wraps the entire original array and sets the position to the given offset:

@Test
void givenByteArray_whenUsingWrapWithParamsMethod_thenConvertToByteBuffer() {
    byte[] givenBytes = {1, 2, 3, 7, 8};
    ByteBuffer buffer = ByteBuffer.wrap(givenBytes, 1, 2);
        
    byte[] actualBytes = new byte[buffer.remaining()];
    buffer.get(actualBytes);
        
    assertArrayEquals(new byte[] {2, 3}, actualBytes);
}

As shown above, we used get() to return the slice because the wrap(array, offset, length) method doesn’t control the underlying array.

3.2. Using ByteBuffer.allocate()

Similarly, we can use the allocate() method to convert a byte array to a ByteBuffer. We should use it combined with put():

@Test
void whenUsingAllocateAndPutMethods_thenConvertToByteBuffer() {
    byte[] givenBytes = {1, 9, 7};
    ByteBuffer buffer = ByteBuffer.allocate(givenBytes.length);
    buffer.put(givenBytes);
    
    assertArrayEquals(givenBytes, buffer.array());
}

In a nutshell, this approach allocates a new buffer and copies the data, which creates complete independence between the buffer and the original array.

However, the buffer position moves to the end after writing with put(). So, we need to call flip() to reset the buffer:

@Test
void givenByteArray_whenUsingPutWithFlip_thenReadWithoutException() {
    byte[] givenBytes = {3, 8};
    ByteBuffer buffer = ByteBuffer.allocate(givenBytes.length);
    buffer.put(givenBytes);
    buffer.flip();
        
    assertEquals(3, buffer.get());
}

Otherwise, reading from the buffer using the get() method may lead to a BufferUnderflowException:

@Test
void givenByteArray_whenUsingPutWithoutFlip_thenThrowBufferUnderflowException() {
    byte[] givenBytes = {1, 5};
    ByteBuffer buffer = ByteBuffer.allocate(givenBytes.length);
    buffer.put(givenBytes);
    assertThrows(BufferUnderflowException.class, buffer::get);
}

As expected, the test case confirms that the get() method throws BufferUnderflowException if we don’t use flip() to reset the buffer position.

4. Conclusion

In this article, we explored various methods for converting between ByteBuffer and byte arrays in Java.

The full source is available over on GitHub.

       

1. Introduction

As developers, we usually repeat the same patterns while writing code. Although each repetition seems small, it gradually slows our workflow. Fortunately, Visual Studio Code provides user-defined snippets, which allow us to expand short triggers into full code templates. As a result, we can reduce repetitive typing, improve consistency, and focus more on solving problems.

In this tutorial, we’ll explain how snippets work in Visual Studio Code and demonstrate how to create and use them effectively.

2. Code Snippets in VS Code

A snippet is a reusable code template that expands when we type a specific keyword. VS Code stores snippets in JSON files, where each definition controls how the editor expands the template.

Typically, a snippet includes three main fields: the prefix, which acts as the trigger keyword; the body, which inserts the code; and the description, which provides a short explanation in IntelliSense.

Once we type the prefix and press Tab (or select it from suggestions), VS Code inserts the snippet into the editor.

VS Code also provides built-in snippets and extension-based snippet packs, so we should check existing options before creating new ones.

3. Creating a Simple Snippet

To start writing a snippet, we first need to open the snippet configuration interface. We can open it through the Command Palette (Ctrl + Shift + P on Windows or Cmd + Shift + P on Mac).

Next, we search for Configure Snippets and proceed to select the desired scope. There are several scopes to choose from, including global snippets that work across all file types and language-specific snippets that apply only to a particular language.

After we make the selection, VS Code lets us choose a name for the file and then opens a JSON file where we can define our snippets.

3.1. Inserting a Header Comment

Let’s create a snippet that inserts a section header comment:

"Section Header": {
  "prefix": "sechead",
  "body": [
    "// ============================",
    "// ${1:Section Title}",
    "// ============================",
    "// ${2:Author}",
    "// ============================"
  ],
  "description": "Insert a section header comment"
}

Here, ${1:Section Title} and ${2:Author} define placeholders and control cursor navigation order.

After saving the file, we can immediately try it out by typing the prefix sechead in a new file or, alternatively, by pressing Ctrl + Space on Windows or Cmd + Space on Mac to open the snippet dropdown. With the snippet selected, pressing Tab or Enter will insert our Section Header:

// ============================
// Section Title
// ============================
// Author
// ============================

Once the snippet is added, the cursor immediately jumps to the first position. After entering the section title, we can press Tab to move it to the next position, which is the author.

3.2. Snippet Shortcuts

Snippets are especially useful for frequently typed statements. For instance, Java developers often write System.out.println() for debugging.

We can create a shortcut like this:

"System.out.println": {
  "prefix": "sysout",
  "body": [
    "System.out.println(${1:value});"
  ],
  "description": "Print a value to the console"
}

After saving, we can type sysout and expand it. VS Code inserts:

System.out.println(value);

The cursor appears inside the parentheses, allowing us to quickly replace the placeholder.

4. Advanced Snippet Controls

Now that we’ve created basic snippets, we can explore more advanced features available in VS Code.

4.1. Language Specific Snippets

Every snippet is scoped to one, several, or all (“global”) languages based on where it is defined.

Single-language user-defined snippets are defined in a specific language’s snippet file (for example, java.json), which we can access through Snippets: Configure Snippets using the language identifier.

For example, we can add a scope to our sysout snippet:

"scope": "java",

By adding this line, we ensure the snippet is available only when we edit files in Java.

Multi-language and global user-defined snippets are all defined in “global” snippet files (JSON with the file extension .code-snippets). For example, we can add another language to the previously defined scope:

"scope": "java,kotlin"

Now, sysout will appear when working with Java or Kotlin files only.

4.2. Choices and Variables

Placeholders can include predefined choices. For example, we can define them using a comma-separated list inside pipe characters, such as ${1|one,two,three|}. When the snippet expands, the editor prompts us to select one of the values, so we can choose quickly instead of typing.

Additionally, we can insert variables using $name or ${name:default}. If the variable exists, the editor inserts its value. Otherwise, it uses the default or an empty string. However, if the variable is unknown, the editor inserts its name and turns it into an editable placeholder.

Let’s rewrite our sysout snippet to use choices and variables:

"Java Log with Choice and Variable": {
  "scope": "java,kotlin",
  "prefix": "sysout",
  "body": [
    "System.out.println(\"[${1|INFO,DEBUG,ERROR|}] ${TM_FILENAME_BASE}: ${2:message}\");"
  ],
  "description": "Log statement with level choice and filename variable"
}

First, ${1|INFO,DEBUG,ERROR|} allows us to select a value when the snippet expands, and we can cycle through the available options (INFO → DEBUG → ERROR).

Next, ${TM_FILENAME_BASE} automatically inserts the current file name without the extension, so we don’t need to type it manually. VS Code provides many predefined variables that we can use in snippets.

Finally, ${2:message} inserts a default value (message) while still allowing us to overwrite it immediately.

4.3. Placeholder Transforms (Regex-Based Manipulation)

In addition to basic placeholders, VS Code supports placeholder transforms, which allow us to modify input using regular expressions. As a result, we can dynamically format text without rewriting it manually.

The syntax follows this structure:

${variable/regex/format/options}

Let’s look at a practical example. Suppose we want to generate a Java getter method where the field name is automatically capitalized:

"Java Getter": {
  "scope": "java",
  "prefix": "getter",
  "body": [
    "public ${1:String} get${2/(.*)/${1:/capitalize}/}() {",
    "    return ${2:fieldName};",
    "}"
  ],
  "description": "Generate getter with capitalized field name"
}

Here, ${2:fieldName} defines the input placeholder. Then, ${2/(.*)/${1:/capitalize}/} transforms that input by capitalizing its first letter.

For example, if we enter userName, the snippet expands to:

public String getUserName() {
    return userName;
}

Therefore, we can reuse user input while automatically adjusting its format. This feature becomes especially useful when generating method names, constants, or formatted identifiers.

4.4. Assigning Keyboard Shortcuts to Snippets

In addition to prefixes, we can trigger snippets using keyboard shortcuts. Let’s open the keybind file for our user by using the Command Palette and typing in Open Keyboard Shortcuts (JSON).

Here, we can define and possibly override existing default keybinds. For our scope, let’s use the shortcut Ctrl + Alt + P on Windows or Cmd + Option + P on Mac :

{
  "key": "ctrl+alt+p",
  "command": "editor.action.insertSnippet",
  "args": {
    "name": "Java Log with Choice and Variable"
  },
  "when": "editorTextFocus && editorLangId == 'java'"
}

Once the file has been saved, we can now quickly insert our custom snippet:

By assigning a keyboard shortcut, we can insert our custom snippet instantly, which improves both speed and workflow efficiency.

5. Conclusion

In this article, we explored how to create and customize snippets in Visual Studio Code to reduce repetitive coding and improve development efficiency.

We first opened the snippet configuration and chose the appropriate scope.

Next, we defined snippets using a prefix, body, and description.

Then, we enhanced them with placeholders, tab stops, choices, variables, and regex-based transforms.

By investing a small amount of time in creating snippets, we can significantly improve our development speed and maintain consistent code across projects.

       

1. Introduction

With Virtual threads, we can scale application performance for any I/O-intensive workflows. By contrast, with the platform threads, we had to carefully manage the expensive operating system resources and utilize non-blocking I/O, which involved complicated asynchronous code like CompletableFuture.

Even though virtual threads solve the scarcity problem with limited operating system threads, certain scenarios can cause platform thread blocking.

In this tutorial, we’ll learn different pinning scenarios with an example code. We’ll also debug and implement the fix for one such example. We’ll also learn the scenarios resolved in JDK 24.

2. Virtual Thread Pinning Scenarios

Virtual threads are a short-lived, lightweight thread construct that gets mounted onto the platform “carrier” thread by the JVM scheduler. It then executes the task and unmounts from the platform thread. The platform thread becomes available for the next task.

However, there are situations where the virtual thread and the corresponding carrier thread get blocked for a longer duration.

While this does not affect the business logic, it hampers the application’s scalability. A few common reasons are running heavy CPU-related tasks, waiting while holding a lock, or being blocked within a native method execution.

Though we should avoid using the virtual threads for any CPU-intensive operation. We’ll still need to understand other scenarios.

2.1. Synchronized Method or Block

Let’s imagine a real-world example of adding products to the shopping cart.

We’ll implement the CartService class with an update method with the productId as a lock:

public class CartService {
    private final Map<String, Integer> products;
    private final Map<String, Object> locks = new ConcurrentHashMap<>();
    public void update(String productId, int quantity) {
        Object lock = locks.computeIfAbsent(productId, k -> new Object());
        synchronized (lock) {
            simulateAPI();
            products.merge(productId, quantity, Integer::sum);
        }
        LOGGER.info("Updated Cart for {} {}", productId, quantity);
    }
}

In the above code, we’re calling a simulated API instead of an actual one for demonstration purposes.

We’ll simulate the downstream API call with a thread sleep method:

private void simulateAPI() {
    try {
        Thread.sleep(50);
    } catch (InterruptedException ex) {
        throw new RuntimeException(ex);
    }
}

Next, we’ll try to debug the above code.

2.2. Debug Pinning

Let’s test the above code using the Java flight recorder.

We’ll verify the pinning by running the CartService update method inside a virtual thread and assert the JFR events:

@Test
void givenJFRIsEnabled_whenVThreadIsBlocked_thenDetectVThreadPinned() throws Exception {
    Path file = Path.of("pinning.jfr");
    try (Recording recording = new Recording()) {
        recording.enable("jdk.VirtualThreadPinned")
          .withThreshold(Duration.ofMillis(1));
        recording.start();
        Thread th = Thread.ofVirtual().start(() ->
            cartService.update("test1", 2));
        th.join();
        recording.stop();
        recording.dump(file);
}
    try (RecordingFile rf = new RecordingFile(file)) {
        assertTrue(rf.hasMoreEvents());
        while (rf.hasMoreEvents()) {
            RecordedEvent event = rf.readEvent();
            System.out.println(event);
            assertEquals("jdk.VirtualThreadPinned", event.getEventType().getName());
            assertEquals("Virtual Thread Pinned", event.getEventType().getLabel());
        }
    }
    Files.delete(file);
}

In the above test, we assert that the RecordedEvent includes the jdk.VirtualThreadPinned event.
Also, we can see the jdk.VirtualThreadPinned event in the console log:

jdk.VirtualThreadPinned {
  startTime = 13:28:30.738 (2026-03-29)
  duration = 101 ms
  eventThread = "" (javaThreadId = 32, virtual)
}

Additionally, we can view the pinned event in the JDK Mission Control dashboard:

Alternatively, we can detect pinning using the -Djdk.tracePinnedThreads=full VM flag:

VirtualThread[#21]/runnable@ForkJoinPool-1-worker-1 reason:MONITOR
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:199)
    java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
    java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:635)
    java.base/java.lang.VirtualThread.sleepNanos(VirtualThread.java:807)
    java.base/java.lang.Thread.sleep(Thread.java:507)
    com.baeldung.virtualthread.synchronize.CartService.simulateAPI(CartService.java:35)
    com.baeldung.virtualthread.synchronize.CartService.update(CartService.java:22) <== monitors:1

The above logs confirm that the platform thread is blocked.

Additionally, any code with Method-level synchronization, synchronization with wait, or the LockSupport.park method causes the pinning.

2.3. Native Method

The pinning can also occur in the native method calls. The native method can block either for any I/O operation or callbacks to Java code, which in turn blocks on a monitor.

We’ll implement a simple native method:

public class NativeDemo {
    static {
        System.loadLibrary("native-lib");
    }
    public native String nativeCall();
}

The reason for the pinning is that the thread has no control on native stack and needs to wait for the native method call to return.

Similarly, we can expect the same when running the native function using the Foreign Function API:

public void execute() {
    LOGGER.info("Running foreign function sleep...");
    Linker linker = Linker.nativeLinker();
    SymbolLookup stdlib = linker.defaultLookup();
    MethodHandle sleep = linker.downcallHandle(stdlib.find("sleep")
      .orElseThrow(), FunctionDescriptor.of(JAVA_INT, JAVA_LONG));
    try {
        sleep.invoke(100);
    } catch (Throwable ex) {
        throw new RuntimeException(ex);
    }
}

In the above code, the foreign function sleep method is defined by first creating the Linker object and then including the downcall MethodHandle instance.

As of JDK 21/24, JFR does not emit the jdk.VirtualThreadPinned event for blocking that occurs within native or FFM code.

Still, we can confirm the pinning by analyzing the thread dump and its impact on other virtual threads.

2.4. Static Initializer Block

Let’s imagine a class with a static initializer block.

We’ll implement a static initializer block with a Thread.sleep method to block the platform thread:

public class HeavyClass {
    static {
        try {
            Thread.sleep(100);
        } catch (InterruptedException ex) {
            throw new RuntimeException(ex);
        }
        LOGGER.info("static initialization done");
    }
}

In the above code, we expect the virtual thread to get pinned as the static initializer holds an intrinsic lock.

2.5. Custom Class Loader

We’ll implement a custom class loader to verify virtual thread pinning in the above scenario.

First, let’s implement a CustomClassLoader class by extending the ClassLoader class and overriding the findClass method:

class CustomClassLoader extends ClassLoader {
    private final Path classDir;
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        LOGGER.info("Finding class for {}", name);
        try {
            Path file = classDir.resolve(name.replace('.', '/') + ".class");
            byte[] bytes = java.nio.file.Files.readAllBytes(file);
            Thread.sleep(100);
            return defineClass(name, bytes, 0, bytes.length);
        } catch (InterruptedException | IOException ex) {
            LOGGER.error("Error while finding class file {}", ex.getMessage());
            throw new ClassNotFoundException(ex.getMessage(), ex);
        }
    }
}

Then, we’ll need to implement the loadClass method to override the system classloader:

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    LOGGER.info("Load class for {}", name);
    Class<?> clazz = findLoadedClass(name);
    if (clazz == null) {
        try {
            clazz = findClass(name);
        } catch (ClassNotFoundException ex) {
            clazz = super.loadClass(name, resolve);
        }
    }
    if (resolve) {
        resolveClass(clazz);
    }
    return clazz;
}

We’ll run a similar test for this class loader with the JFR recording enabled and verify the pinned thread event.

This is also true for any virtual thread that uses the same class while another thread initializes it.

3. Implement Synchronization Without Pinning

Although the JVM tries to compensate for the pinning by temporarily increasing the parallelism of the virtual thread scheduler, subjected to the default maximum of 256.
Still, we can overcome this with Java’s advanced concurrency control support.

We can use the Loom-aware locking mechanism, such as the ReentrantLock or ReadWriteLock class. The lock implementation within the java.util.concurrent.locks package does not cause the pinning.

We’ll implement the above CartService’s update method using the ReentrantLock lock:

public void update(String productId, int quantity) {
    Lock lock = locks.computeIfAbsent(productId, k -> new ReentrantLock());
    try {
        if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
            try {
                simulateAPI();
                products.merge(productId, quantity, Integer::sum);
            } finally{
                lock.unlock();
            }
            LOGGER.info("Updated Cart for {} {}", productId, quantity);
        }
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
}

If we run the earlier test again with the fixed version, we don’t observe any thread pinning event and blocking in the other threads.

Another approach to resolving the unnecessary pinning is to upgrade to JDK 24 or newer versions, where developers have fixed the issue.
We recommend upgrading the Java version if the upgrading effort is significantly smaller than reimplementing the code across services.

4. Pinning Scenarios Resolved in JDK 24

As part of JEP-491, the pinning issue is resolved for the synchronize method and block.
The Java team changed the implementation of the synchronized keyword, and now the virtual thread can acquire, hold, and release the lock independently of its carrier thread.

The system still expects pinning in the native method, class loader, and class initializer.

5. Benchmark

We’ll implement a JMH benchmark test for the earlier CartService update method with the AverageTime and Throughput modes:

@BenchmarkMode({ Mode.AverageTime, Mode.Throughput })
@OutputTimeUnit(TimeUnit.SECONDS)
@Warmup(iterations = 1, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
@Fork(value = 2)
@State(Scope.Benchmark)
public class BenchmarkVirtualThread {
    private final CartService cartService = new CartService();
    @Param({"100", "1000", "10000"})
    private int CONCURRENCY;
    @Benchmark
    public void benchmark() throws InterruptedException, IOException {
        List<Thread> threads = new ArrayList<>();
        IntStream.range(0, CONCURRENCY).forEach(i ->
            threads.add(Thread.startVirtualThread(() -> cartService.update(UUID.randomUUID().toString(), 2))));
        threads.forEach(th -> {
            try {
                th.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }
}

In the above test, we’re using the benchmark parameter for concurrency control, and iterating the method 3 times after the initial warm-up.

We’ll now execute the above benchmark test in both JDK 21 and 25 versions.

First, we’ll see the performance report for JDK 21 version:

Benchmark                         (CONCURRENCY)   Mode  Cnt   Score    Error  Units
BenchmarkVirtualThread.benchmark            100  thrpt    6   2.081 ±  0.008  ops/s
BenchmarkVirtualThread.benchmark           1000  thrpt    6   0.214 ±  0.058  ops/s
BenchmarkVirtualThread.benchmark          10000  thrpt    6   0.023 ±  0.001  ops/s
BenchmarkVirtualThread.benchmark            100   avgt    6   0.479 ±  0.011   s/op
BenchmarkVirtualThread.benchmark           1000   avgt    6   4.468 ±  0.033   s/op
BenchmarkVirtualThread.benchmark          10000   avgt    6  44.056 ±  0.279   s/op

Then, let’s confirm the report for JDK 25 version:

Benchmark                         (CONCURRENCY)   Mode  Cnt   Score   Error  Units
BenchmarkVirtualThread.benchmark            100  thrpt    6  18.392 ± 0.206  ops/s
BenchmarkVirtualThread.benchmark           1000  thrpt    6  10.061 ± 0.170  ops/s
BenchmarkVirtualThread.benchmark          10000  thrpt    6   1.005 ± 0.029  ops/s
BenchmarkVirtualThread.benchmark            100   avgt    6   0.058 ± 0.015   s/op
BenchmarkVirtualThread.benchmark           1000   avgt    6   0.108 ± 0.036   s/op
BenchmarkVirtualThread.benchmark          10000   avgt    6   0.962 ± 0.030   s/op

From the above data, we can confirm that the throughput and average time have significantly improved in the latest JDK version.

6. Conclusion

In this article, we’ve learned. We’ve implemented a fix for the synchronized method scenario. Also, we’ve explored how, in the later version, some of the pinning issues are resolved.

As always, the example code can be found over on GitHub.

       

1. Introduction

Cryptographic key management has always been a central concern in secure application development using Java.

Java 25 introduced the Key Derivation Function (KDF) API after its first preview in JDK 24 under JEP 478. This new API introduces a clean, extensible model for deriving cryptographic keys from initial key material using well-established algorithms.

In this article, we’ll explore the motivation behind the Key Derivation Function (KDF) API, the architecture of the new API and its core components.

2. Motivation Behind KDFs

A Key Derivation Function takes some initial key material (IKM) and derives one or more cryptographically strong keys from it.

We can think of IKM as the raw cryptographic seed fed into the function. IKMs can be a shared secret negotiated over a network, a user-supplied password, or entropy produced by a key agreement protocol.

Let’s see where KDFs are useful:

• TLS and protocol handshakes: After a Diffie-Hellman or ECDH exchange, the raw shared secret shouldn’t be used directly. A KDF transforms it into session keys with the required length and entropy.
• Password-based encryption: Raw passwords are weak keys. Algorithms like PBKDF2 stretch and salt passwords to produce secure cryptographic material.
• Key diversification: A single master key can be safely expanded into multiple purpose-specific sub-keys without compromising the original.

Before Java 25, there was no unified API to express any of these use cases. Therefore, developers either relied on low-level MAC-based constructions, vendor-specific provider APIs, or embedded third-party libraries such as Bouncy Castle.

The new KDF API solves this by offering a standard, JCA-integrated interface that is both algorithm-agnostic and provider-extensible.

3. Architecture of the New KDF API

The KDF API lives in the javax.crypto package and follows the same factory-method pattern that Java’s existing cryptographic APIs use:

KDF kdf = KDF.getInstance("HKDF-SHA256");

The factory pattern is a creational design pattern. It provides a way to create objects, generally with the getInstance() method, without having to specify the class of the object that will be created.

In our case getInstance() method accepts an algorithm name and, optionally, a Provider. This keeps the API consistent with the broader JCA architecture and allows alternative implementations to be plugged in without changing application code.

Once obtained, a KDF instance can derive either a typed SecretKey or raw byte material as follows:

SecretKey key = kdf.deriveKey("AES", paramSpec);
byte[] rawKeyMaterial = kdf.deriveData(paramSpec);

4. Derivation Methods

Let’s discuss how the KDF class exposes the primary derivation methods:

4.1. deriveKey(String alg, AlgorithmParameterSpec params)

The first method deriveKey(), as the name suggests, derives a SecretKey for the specified target algorithm. Internally, the provider uses the params to determine the required key length and derivation inputs. The returned key is then ready to be used with the corresponding JCA algorithm:

SecretKey aesKey = kdf.deriveKey("AES", hkdfParams);
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, aesKey, gcmSpec);

4.2. deriveData(AlgorithmParameterSpec params)

The deriveData() method, on the other hand, returns the derived bytes directly as a byte[]. It’s useful when the downstream consumer isn’t a JCA algorithm, for example, when feeding the output into a MAC or a custom protocol:

byte[] okm = kdf.deriveData(hkdfParams);

We should note that both methods throw the InvalidAlgorithmParameterException if the parameter specification is incompatible with the chosen algorithm, and NoSuchAlgorithmException propagates from the getInstance() method if the algorithm isn’t available from any loaded provider.

5. Input Parameters

In this section, let’s understand what input parameters are required to apply and use the KDF API.

The KDF API uses AlgorithmParameterSpec implementations to carry derivation inputs. 

For HKDF, the JDK provides a class that models the three distinct phases of the HKDF specification (RFC 5869): Extract, Expand, and the combined Extract-then-Expand. HKDFParameterSpec class is at the centre of this.

Each method comes with a different set of methods chained and expects a different set of parameters.

5.1. Extract-then-Expand

The first approach is an extract followed by an expand based approach:

HKDFParameterSpec params = HKDFParameterSpec
  .ofExtract()
  .addIKM(ikm)
material.addSalt(salt) // optional, randomizes extraction
  .thenExpand(info, 32);

It exposes an extract() method that returns a builder. We then call thenExpand() on it and seal the spec. This signals that both phases should run together.

The info parameter is a context-binding byte array that ties the derived key to a specific purpose (e.g. encryption vs authentication).

5.2. Extract-only

In this approach, the HKDFParameterSpec only utilises extraction:

HKDFParameterSpec extractOnly = HKDFParameterSpec
  .ofExtract()
  .addIKM(ikm)
  .addSalt(salt)
  .extractOnly();

This produces a pseudorandom key (PRK) from the IKM and salt without expanding it. We can then store or pass the PRK to a subsequent Expand-only step.

5.3. Expand-only

Finally, let’s talk about the expand-only scenario:

HKDFParameterSpec expandOnly = HKDFParameterSpec
  .expandOnly(prk, info, 64);

Here, prk is a previously derived SecretKey. This is useful in protocols that separate the extract and expand phases across different stages of a handshake.

6. Supported Algorithms in Java 25

Java 25 ships with built-in support for the HKDF family of algorithms through the default SunJCE provider.

The supported algorithm names are:

• HKDF-SHA256
• HKDF-SHA384
• HKDF-SHA512

All three follow the HMAC-based Extract-and-Expand construction defined in RFC 5869. The maximum output length for each variant is 255 times the hash output length, as mandated by the specification.

7. Comparing the Old and the New

Before the KDF API, deriving a key using HKDF required implementing the Extract and Expand steps manually using javax.crypto.Mac:

Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(salt, "HmacSHA256"));
byte[] prk = mac.doFinal(ikm);
mac.init(new SecretKeySpec(prk, "HmacSHA256"));
byte[] t = new byte[0];
byte[] okm = new byte[32];
byte counter = 1;
mac.update(t);
mac.update(info);
mac.update(counter);
t = mac.doFinal();
System.arraycopy(t, 0, okm, 0, 32);
SecretKey aesKey = new SecretKeySpec(okm, "AES");

This is fragile, verbose, and easy to get wrong. Additionally, it also conflates cryptographic logic with application code, making audits harder.

The new API reduces the same operation to a self-documenting, three-line construct:

KDF hkdf = KDF.getInstance("HKDF-SHA256");
SecretKey aesKey = hkdf.deriveKey("AES",
HKDFParameterSpec.ofExtract()
  .addIKM(ikm)
  .addSalt(salt)
  .thenExpand(info, 32));

The algorithm name is validated at instantiation time, not buried in a string passed to Mac.getInstance().

Finally, let’s talk a little bit about error handling. Parameter errors surface as typed exceptions rather than silent data corruption. This was a missing piece in the older approach.

Since KDF has a provider-backed implementation, a security team can exchange the underlying algorithmic implementation, for example, to a FIPS-compliant provider without touching application code. This makes the new KDF Spec design much more robust.

8. Conclusion

In this article, we explored the Key Derivation Function API introduced in Java 25. We looked at why KDFs are essential in modern cryptographic workflows, how the KDF class fits into the existing JCA architecture, and how HKDFParameterSpec models the Extract and Expand phases of the HKDF specification.

We also saw how the new API eliminates the manual, error-prone workarounds that developers previously had to write, replacing them with a clean, algorithm-agnostic, and provider-extensible interface.

The full source code for the examples in this article is available over on GitHub.

       

1. Overview

Large Language Models (LLMs) have advanced to agentic systems capable of executing tasks more complex than simply generating text. One of the emerging areas is agent skills as introduced by Antropic.

Agent skills enable LLM to produce document files without an additional API, such as Apache POI. They invoke the built-in capabilities that generate documents on the provider server and return them via file identifiers. Spring AI supports skills with the Anthropic models, making it easy to integrate with Java applications.

In this tutorial, we’ll explore what Anthropic provides in terms of agent skills and how we integrate them with Spring AI.

2. Anthropic Pre-built Skills

Anthropic provides a set of pre-built agent skills that can generate a document and populate it with content. Thus, the model can return a document file rather than plain text.

Of course, there are a few document formats that Anthropic currently supports:

• DOCX: Word documents with formatting
• PDF: Formatted PDF reports
• PPTX: PowerPoint slides
• XLSX: Excel spreadsheets

In Spring AI, we can use these Anthropic pre-built skills by applying them via chat options.

3. Configuration

To get started with the Anthropic skills, let’s add the required dependency to pom.xml:

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-anthropic</artifactId>
</dependency>

Next, we configure the Anthropic API key in application.yml to use Anthropic models:

spring:
  ai:
    anthropic:
      api-key: "${ANTHROPIC_API_KEY}"

This way, we don’t need to supply the key separately.

4. Sample Implementation

To demonstrate the features, let’s build a simple web application that generates a sales report. Moreover, the implementation enables us to output a specific document format supported by the pre-built skills via the request prompt.

4.1. Data Service

To begin with, we need to provide a model to represent the data sent to the chat model:

public record MonthlySale(String product, int year, Month month, BigDecimal amount) {
}

For demonstration purposes, we create a simple data service layer to return hardcoded data. In this case, the service returns a List of MonthlySale containing 12 months of sales for product A and product B:

@Service
public class MonthlySalesService {
    public List<MonthlySale> getMonthlySalesForYear(int year) {
        return List.of(
            // Product A monthly sales
            new MonthlySale("Product A", year, Month.JANUARY, new BigDecimal("1200")),
            new MonthlySale("Product A", year, Month.FEBRUARY, new BigDecimal("1325")),
            ...
            // Product B monthly sales
            ...
            new MonthlySale("Product B", year, Month.NOVEMBER, new BigDecimal("1330")),
            new MonthlySale("Product B", year, Month.DECEMBER, new BigDecimal("1395"))
        );
    }
}

In reality, we could replace it with an MCP tool to retrieve the sales data from the database and integrate it with the chat model.

4.2. Controller

Next, we expose an HTTP endpoint to accept a request prompt that shapes the document content and format.

Since the document format isn’t known in advance, we return the mime type, which is determined from the chat model, to the client:

@RestController
@RequestMapping("/agent-skills")
@Validated
public class AgentSkillsController {
    private final AgentSkillsService agentSkillsService;
    public AgentSkillsController(AgentSkillsService agentSkillsService) {
        this.agentSkillsService = agentSkillsService;
    }
    @GetMapping("/report")
    public ResponseEntity<byte[]> genReport(@RequestBody @Valid ReportRequest reportRequest) {
        AnthropicDocument document = agentSkillsService.genReport(reportRequest);
        return ResponseEntity.ok()
          .contentType(MediaType.parseMediaType(document.mimeType()))
          .header(HttpHeaders.CONTENT_DISPOSITION,
            ContentDisposition.attachment()
              .filename(document.fileName())
              .build()
              .toString())
          .body(document.content());
    }
}

Let’s introduce a simple placeholder record:

public record ReportRequest(@NotNull String prompt) {
}

This holds the prompt message input by the user, which gets passed to the AgentSkillService.

4.3. Agent Skill Service

Now, we create a service to generate a document using the Anthropic chat model with the pre-built skills. The Anthropic chat options can support multiple skills. 

In this example, we put all the available pre-built skills into the chat model, and employ the user prompt to control what document format we would like to produce. This aims to demonstrate that the chat model can select the appropriate skill based on the prompt.

However, it’s usually better to enable the required skills only to reduce the chance of outputting an unpredictable format:

@Service
public class AgentSkillsService {
    private final AnthropicChatModel chatModel;
    private final AnthropicApi anthropicApi;
    private final MonthlySalesService monthlySalesService;
    public AgentSkillsService(
      AnthropicChatModel chatModel,
      AnthropicApi anthropicApi, 
      MonthlySalesService monthlySalesService) {
        this.chatModel = chatModel;
        this.anthropicApi = anthropicApi;
        this.monthlySalesService = monthlySalesService;
    }
    public AnthropicDocument genReport(ReportRequest reportRequest) {
        ChatResponse response = ChatClient.create(chatModel)
          .prompt()
          .system( "Given the dataset of monthly sales for our product: " 
            + monthlySalesService.getMonthlySalesForYear(2025))
          .user(reportRequest.prompt())
          .options(AnthropicChatOptions.builder()
            .model("claude-sonnet-4-5")
            .skill(AnthropicApi.AnthropicSkill.DOCX)
            .skill(AnthropicApi.AnthropicSkill.PDF)
            .skill(AnthropicApi.AnthropicSkill.PPTX)
            .skill(AnthropicApi.AnthropicSkill.XLSX)
            maxTokens(4096)
            .build())
          .call()
          .chatResponse();
        List fileIds = AnthropicSkillsResponseHelper.extractFileIds(response);
        if (fileIds.isEmpty()) {
            throw new IllegalStateException("No document was generated by the skill");
        }
        return downloadReport(fileIds.get(0));
    }
    public AnthropicDocument downloadReport(String fileId) {
        AnthropicApi.FileMetadata metadata = anthropicApi.getFileMetadata(fileId);
        byte[] content = anthropicApi.downloadFile(fileId);
        return new AnthropicDocument(metadata.filename(), metadata.mimeType(), content);
    }
}

Notably, we set the maxTokens to 4096 to control the maximum amount of content that could be generated in a response. As a rule of thumb, one (1) token is roughly equal to four (4) characters. In this case, 4096 should be more than sufficient. However, we could extend it to a larger size if we expect a lengthy report.

Once we receive the response from the chat model, we can use the AnthropicSkillsResponseHelper to extract the file ID from that response. This file ID uniquely identifies the generated file stored on the Anthropic server.

Let’s check the files in the Claude console:

Thus, we use the AnthropicAPI provided by Spring AI to obtain the file information based on the file ID. Of course, the AnthropicApi.FileMetadata contains details about the file:

• file name
• file size
• creation date
• MIME type

While AnthropicDocument is a simple Java record to store the file name, the mime type and the file content, it returns them to the client via the controller:

public record AnthropicDocument(String fileName, String, mimeType, byte[] content) {
}

Thus, we have the basic application ready for testing.

5. Test Run

Everything is set, and we can start testing. To that end, let’s call the endpoint using Postman to trigger the request.

5.1. PDF Report

To begin with, we create an example request for generating a sales report with a summary and a table in PDF format:

At this point, we see the content, including the monthly sales table and a summary in the generated file:

So, all information is there and in a structured format.

5.2. Excel Spreadsheet

Let’s change the prompt to generate an Excel spreadsheet instead, with a bar chart instead of a summary:

{
    "prompt": "Create a Excel spreadsheet for our product monthly sales. Include a monthly sales table, and a monthly bar chart next to the table."
}

Now, the report reflects the format change:

So, we see the spreadsheet with the correct data and formatting.

6. Conclusion

In this article, we explored how to integrate the pre-built agent skills of Anthropic with a chat model to generate various documents using Spring AI.

Furthermore, we demonstrated how to use a prompt to control the actual output document format. In particular, this provides flexibility to generate different document formats without changing the application logic.

As usual, the complete code examples are available over on GitHub.

       

1. Spring and Java

>> Teaching an AI Agent to Debug Flaky Tests [jetbrains.com]

A practical look at how JetBrains is training an AI agent to triage flaky tests. All about pinpointing the actual root cause and proposing a fix, rather than leaving developers to chase intermittent red builds. A interesting data point of where AI tooling is genuinely moving the needle in day-to-day Java development.

Also worth reading:

• >> BoxLang AI Deep Dive — Part 6 of 7: Memory Systems & RAG [foojay.io]
• >> The Code Was Always the Door [foojay.io]
• >> JobRunr Introduces ClawRunr, an Open-Source Java AI Agent [infoq.com]
• >> Introducing Quarkus Agent MCP [quarkus.io]
• >> Faster Startup on IBM Semeru with OpenJ9 Shared Classes Cache [quarkus.io]
• >> Designing a team of agents [frankel.ch]
• >> The HashiCorp Vault integration for WildFly 40 Beta [wildfly.org]
• >> Hibernate Tools Moves to Hibernate ORM—and Eclipse Tooling Retires [in.relation.to]
• >> Why JOIN USING Can Lead to Errors in SQL [jooq.org]

Webinars and presentations:

• >> Foojay Podcast #94: More Than a Blog [foojay.io]
• >> Podcast: Roq: Leveraging Quarkus to Build Static Sites at the Speed of Go [infoq.com]
• >> Episode 57 “Make Java Safer with Flexible Constructor Bodies” [inside.java]
• >> Spring Office Hours Podcast: S5E14 – Spec Driven Development with Simon Martinelli [spring.io]

Time to upgrade:

• >> IntelliJ IDEA 2025.3.5 is Out! [jetbrains.com]
• >> Quarkus 3.35 – JAR tree-shaking, PGO for native, Semeru AOT [quarkus.io]
• >> Emergency releases to fix CVE-2026-39852 in all supported streams [quarkus.io]
• >> New WildFly 40 Beta release [wildfly.org]
• >> Jetty 12.1.9 and 12.0.35 [github.com/jetty]
• >> Elasticsearch 9.4.0, 9.3.4 and 8.19.15 [github.com/elastic]
• >> Zuul 3.6.3 [github.com/Netflix]
• >> Grails 7.1.1 and 7.0.11 [github.com/grails]
• >> Micronaut Core 4.10.23 [github.com/micronaut-projects]
• >> JEP 533: Structured Concurrency (Seventh Preview) [openjdk.org]
• >> JEP 531: Lazy Constants (Third Preview) [openjdk.org]

2. Technical & Musings

Also worth reading:

• >> Content for Content’s Sake [lucumr.pocoo.org]
• >> Democratizing Machine Learning at Netflix: Building the Model Lifecycle Graph [netflixtechblog.com]
• >> State of Routing in Model Serving [netflixtechblog.com]
• >> Avoiding MCP Confused Deputy With AAuth [christianposta.com]

3. Pick of the Week

>> What to Do [paulgraham.com]

       

1. Introduction

Apache Camel is a Java-based integration framework that implements Enterprise Integration Patterns (EIPs).

In this article, we’ll demonstrate how to use Apache Camel observability-related components to monitor application health and performance.

2. Maven Dependencies

The two variants of this application, Spring Boot and Standalone, send spans and traces by utilizing different tools. To that end, it’s crucial to present the dependency lists separately.

2.1. Spring Boot

To start, for the Spring Boot examples, we need to define the dependencies for spring-boot-starter, camel-spring-boot-starter, spring-boot-starter-actuator, camel-observation-starter, micrometer, and zipkin:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>3.5.11</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.5.11</version>
    </dependency>
    <dependency>
        <groupId>org.apache.camel.springboot</groupId>
        <artifactId>camel-spring-boot-starter</artifactId>
        <version>4.18.0</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
        <version>3.5.11</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator-autoconfigure</artifactId>
        <version>3.5.11</version>
    </dependency>
    <dependency>
        <groupId>org.apache.camel.springboot</groupId>
        <artifactId>camel-observation-starter</artifactId>
        <version>4.18.0</version>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-tracing</artifactId>
        <version>1.5.0</version>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-tracing-bridge-brave</artifactId>
        <version>1.5.0</version>
    </dependency>
    <dependency>
        <groupId>io.zipkin.reporter2</groupId>
        <artifactId>zipkin-reporter-brave</artifactId>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-prometheus</artifactId>
        <version>1.5.0</version>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-core</artifactId>
        <version>1.15.9</version>
    </dependency>
    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-core</artifactId>
        <version>1.5.32</version>
    </dependency>
    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.5.32</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

For the Spring Boot variant, the application generates observations using Micrometer, which the micrometer-tracing-bridge-brave transforms to Brave spans. The zipkin-reporter-brave then sends the transformed spans to the Zipkin backend, which is Jaeger in our case. Finally, the spring-boot-actuator-autoconfigure dependency binds everything together by configuring and instantiating the components that send the spans to Jaeger.

2.2. Camel Standalone

Likewise, for the Camel Standalone application monitoring, we need camel-core, camel-main, camel-observability-services, and camel-opentelemetry2:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-core</artifactId>
    <version>4.17.0</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-main</artifactId>
    <version>4.17.0</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-observability-services</artifactId>
    <version>4.17.0</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-opentelemetry2</artifactId>
    <version>4.17.0</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.5.29</version>
    <scope>compile</scope>
</dependency>

In this version, the camel-observability-services dependency provides preconfigured components for exporting traces and health metrics. In the examples, we employ the OpenTelemetry Java agent to send the traces to Jaeger.

3. Application Under Monitoring

Now, let’s ensure we have a subject for the observations. To begin with, we create an application that reads XML files from a directory, processes them by adding the current timestamp, and copies them to another directory.

In a Camel application, Routes define how data is processed, and the RouteBuilder interface enables us to configure the application routes using Java-DSL. Before we create the RouteBuilder, let’s write the SimpleProcessor, which gets utilized by the RouteBuilder, and is identical for both application variants:

public class SimpleProcessor implements Processor {
    private static final DocumentBuilderFactory factory = DocumentBuilderFactory.newDefaultInstance();
    @Override
    public void process(Exchange exchange) throws Exception {
        String body = exchange.getMessage().getBody(String.class);
        String processedAt = LocalDateTime.now().toString();
        InputStream stream = new ByteArrayInputStream(body.getBytes(StandardCharsets.UTF_8));
        Document document = factory.newDocumentBuilder().parse(stream);
        Element root = document.getDocumentElement();
        Element newElemeent = document.createElement("processed");
        newElemeent.setTextContent(processedAt);
        root.appendChild(newElemeent);
        TransformerFactory transformerFactory = TransformerFactory.newInstance();
        Transformer transformer = transformerFactory.newTransformer();
        transformer.setOutputProperty(OutputKeys.INDENT, "yes");
        StringWriter stringWriter = new StringWriter();
        transformer.transform(new DOMSource(document), new StreamResult(stringWriter));
        String newBody = stringWriter.toString();
        exchange.getMessage().setBody(newBody);
    }
}

With the processor in place, it’s now time to write the RouteBuilder component, which is almost the same for both Spring Boot and Standalone applications, except for the dependency injection code. Moreover, the Spring Boot RouteBuilder, named SimpleRouteBuilder, uses the constructor injection approach:

public class SimpleRouteBuilder extends RouteBuilder {
    private final SimpleProcessor simpleProcessor;
    @Autowired
    public SimpleRouteBuilder(SimpleProcessor simpleProcessor) {
        this.simpleProcessor = simpleProcessor;
    }
    public void configure() {
        from("file://src/data?noop=true")
          .choice()
          .when(xpath("/person/city = 'London'"))
            .log("UK message")
            .to("file:target/messages/uk")
            .log("UK message 2")
            .process(simpleProcessor)
            .to("file:target/messages/general-sink")
          .otherwise()
            .log("Other message")
            .to("file:target/messages/others")
            .log("Other message 2")
            .process(simpleProcessor)
            .to("file:target/messages/general-sink");
    }
}

For the Standalone application RouteBuilder, we use the @BeanInject annotation, which injects a registered component from the Camel Registry:

public class SimpleRouteBuilder extends RouteBuilder {
    @BeanInject("SimpleProcessor")
    SimpleProcessor simpleProcessor;
// the rest of the file is the same as the Spring Boot SimpleRouteBuilder

Finally, we implement the application that combines all the moving parts. Let’s start by writing the @SpringBootApplication annotated main class:

@CamelObservation
@SpringBootApplication
public class CamelSpringBootApplication {
	public static void main(String[] args) {
            SpringApplication.run(FirstCamelSpringBootApplication.class, args);
	}
	@Bean
	SimpleProcessor simpleProcessor() {
	    return new SimpleProcessor();
	}
	@Bean
	SimpleRouteBuilder simpleRouteBuilder(SimpleProcessor simpleProcessor) {
	    return new SimpleRouteBuilder(simpleProcessor);
	}
}

The CamelSpringBootApplication is annotated with the @CamelObservation annotation and defines the required Spring beans. Additionally, the @CamelObservation annotation, which is included in the camel-observation-starter dependency, configures Micrometer Observation to generate metrics and traces for Camel routes.

Similarly, in the Standalone application that we called MainApp, we configure the Camel context using SimpleRouteBuilder and SimpleProcessor:

public class MainApp {
    public static void main(String... args) throws Exception {
        Main main = new Main();
        main.configure().addRoutesBuilder(new SimpleRouteBuilder());
        main.bind("SimpleProcessor", new SimpleProcessor());
        main.run(args);
    }
}

Furthermore, to execute the MainApp.main() method, we configure the camel-maven-plugin:

<plugin>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-maven-plugin</artifactId>
    <version>3.18.4</version>
    <configuration>
        <logClasspath>true</logClasspath>
        <mainClass>com.baeldung.camel.observability.MainApp</mainClass>
    </configuration>
</plugin>

Indeed, camel-maven-plugin enables us to start the Camel Standalone application by executing a simple mvn command:

mvn camel:run

Also, let’s enable opentelemetry2 components via config properties in the application.yml:

camel:
  opentelemetry2:
    enabled: true
    trace-processors: true
    trace-headers-inclusion: true

Lastly, to ensure that every application interaction gets reported, sampling probability needs tweaking as well:

management:
  tracing:
    sampling:
      probability: 1.0

On the other hand, the Standalone variant requires only the opentelemetry2 enablement:

camel.opentelemetry2.enabled=true

Thus, we should be ready for monitoring.

4. Monitoring Setup and Presentation

Conveniently, we monitor traces on the Jaeger server for both application variants.

4.1. Jaeger Deployment

Let’s deploy the Jaeger server as a Docker container:

docker run --name jaeger -p 16686:16686 -p 4317:4317 -p 4318:4318 -p 5778:5778 -p 9411:9411 cr.jaegertracing.io/jaegertracing/jaeger:2.15.0

This way, we can have a ready deployment without the hassle of manual setup.

4.2. Spring Boot

There are no additional steps needed for the Spring Boot application monitoring, so let’s start the application:

mvn spring-boot:run

Now, it’s time to navigate to Jaeger’s dashboard to find the traces. The dashboard URL is http://localhost:16686. To find the relevant traces, we use the application name as a service filter and file as the operation filter:

Subsequently, by clicking and expanding the first trace, we can inspect its contents in detail:

The nested spans contain the individual file operations:

Once again, it’s important to mention that all this functionality is the out-of-the-box behavior of the dependencies we’ve used.

4.2. Standalone

To enable tracing for the Standalone application, let’s use a slightly different mvn command, so that the opentelemetry-java agent sends traces to Jaeger:

MAVEN_OPTS="-javaagent:path/to/opentelemetry-javaagent.jar -Dotel.service.name=camel-standalone" mvn camel:run

In the Jaeger dashboard, we use the Camel Standalone application name as a value for the service filter:

As expected, the span contents for the Camel Standalone application are no different from the Spring Boot application spans.

5. Conclusion

In this article, we demonstrated how to configure a Camel application to generate and send traces to a Jaeger server.

Specifically, we provided examples for both Spring Boot and Camel Standalone applications to ensure a good comparison between the two variants.

In summary, with the proper setup and regardless of the application architecture, using Apache Camel is a fairly straightforward way to monitor an application.

       

1. Overview

Testing is an essential part of the application build process. Of course, it takes time, so we should look for ways to speed it up. The obvious way is to leverage multi-core processors and run tests in parallel.

In this tutorial, we’ll learn how to perform parallel testing with Gradle.

2. The Gradle Setup

Throughout this article, we’ll use Gradle version 9.

First, let’s set it up for parallel testing. We’ll start with the gradle.build file:

plugins {
    id 'java-library'
}
test {
    maxParallelForks = (int) (Runtime.runtime.availableProcessors() / 2 + 1)
    useJUnitPlatform {
        includeTags testForGradleTag
    }
}
repositories {
    mavenCentral()
}
dependencies {
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

Note the maxParallelForks property set to the number of threads that will execute the tests in parallel. We use the Java Runtime availableProcessors() function to assign half and one available cores for tests.

Next, with the useJUnitPlatform property, we invoke and configure the JUnit 5 test environment. We use includeTags to allow filtering tests by the @Tag annotation. To complete the configuration, we need to set the Gradle testForGradleTag property to its default value. Let’s do that in the gradle.properties file:

testForGradleTag=serial

With this default setting, we’ll run only tests marked with the @Tag(“serial”) annotation. It’s an optional setting designed to make the testing more straightforward for us. It has nothing to do with Gradle test forking.

3. How It Works

To understand how parallel testing works, let’s create a test class called UnitTestClass1.

First, let’s prepare the functions to measure the execution time of a particular test and the whole suite:

@Tag("parallel")
@Tag("UnitTest")
public class UnitTestClass1 {
    private long start;
    private static long startAll;
    @BeforeAll
    static void beforeAll() {
        startAll = Instant.now().toEpochMilli();
    }
    @AfterAll
    static void afterAll() {
        long endAll = Instant.now().toEpochMilli();
        System.out.println("Total time: " + (endAll - startAll) + " ms");
    }
    @BeforeEach
    void setUp() {
        start = Instant.now().toEpochMilli();
    }
    private LocalTime localTimeFromMilli(long time) {
        return Instant.ofEpochMilli(time)
          .atZone(ZoneId.systemDefault())
          .toLocalTime();
    }
}

Next, let’s add four test methods, annotated with @Test. We name them whenAny_thenCorrect1() through whenAny_thenCorrect4(). Here is the first one:

@Test
public void whenAny_thenCorrect1() throws InterruptedException {
    Thread.sleep(1000L);
    assertTrue(true);
}

At this moment, they’re identical and do nothing but sleep for one second.

Finally, the tearDown() method provides test statistics:

@AfterEach
void tearDown(TestInfo testInfo) {
    long end = Instant.now().toEpochMilli();
    String name = testInfo.getDisplayName();
    System.out.println("Test " + name + " from class " + getClass().getSimpleName() +
      " started at " + localTimeFromMilli(start) + " ended at " + localTimeFromMilli(end) + 
      ": (" + (end - start) + " ms)");
}

We report both the test display name and the test class name to track the execution order.

3.1. One Test Class

To test only one class, let’s change the annotation of UnitTestClass1 to serial:

@Tag("serial")
@Tag("UnitTest")
public class UnitTestClass1

Then, we can start this class test with Gradle:

$ ./gradlew -i cleanTest test -PtestForGradleTag=serial | grep "Test whenAny"

We start ./gradlew with the -i option for the info debug level. Then we filter the output of the tearDown() method with grep. Let’s study this output:

We see that individual test methods are run in serial, one after another. It’s clearly visible when we compare the start times of subsequent test methods, in the yellow frame.

3.2. Many Test Classes

To benefit from the parallel testing, we need many test classes, not methods. So, let’s just copy our UnitTestClass1 three times. We number new classes from 2 to 4 and ensure they’re annotated with @Tag(“parallel”). Then, we start the test again:

$ ./gradlew -i cleanTest test -PtestForGradleTag=parallel -PtestForGradleTag=UnitTest | grep "Test whenAny"

Now we have 16 test runs. When we go through the logs in chronological order, we see that test methods of different classes started almost simultaneously. So, Gradle runs three threads in parallel. On the other hand, if we sort out the output of one class, we find out that its methods are called in serial, as in the example with one class.

4. Working With Resources

When the test calls for a resource, we should guarantee a clear distinction between independent test runs. Let’s take a look at a simple class designed to create a folder:

public class FolderCreator {
    Boolean createFolder(Path path, String name) throws IOException {
        String newFolder = path.toAbsolutePath() + name;
        File f = new File(newFolder);
        return f.mkdir();
    }
}

The mkdir() function returns false if folder creation failed. It may happen if the folder already exists.

4.1. The Integration Test

Let’s test this method with the TestFolderCreator1 test class. As we interact with the operating system, we tagged this test as integration:

@Tag("parallel")
@Tag("integration")
public class TestFolderCreator1 {
    //time reporting helper functions as in UnitTestClass1
    private Path baseFolder = Paths.get(
      getClass()
      .getResource("/")
      .getPath());
    private Integer workerID = Integer.valueOf(System.getProperty("org.gradle.test.worker", "1"));
    private String testFolderName = "/" + "Test_" + workerID;
    @BeforeEach
    void setUp() {
        start = Instant.now().toEpochMilli();
        //preemptive clean up with helper function
        removeTestFolder();
    }
    private void removeTestFolder() {
        File folder = new File(
          baseFolder.toFile()
          .getAbsolutePath() + testFolderName);
        folder.delete();
    }
}

The structure of this class is similar to that of UnitTestClass1. However, in the setUp() method, we ensure that the test folder doesn’t exist, preemptively removing it.

Now let’s look at the test function whenCreated_ThenCorrect():

@Test
void whenCreated_ThenCorrect() throws IOException, InterruptedException {
    FolderCreator folderCreator = new FolderCreator();
    assertTrue(folderCreator.createFolder(baseFolder, testFolderName));
    Thread.sleep(1000L);
}

It asserts that the folder creation is successful. Unlike in the previous example, we have only one test function now.

Finally comes the tearDown() function:

@AfterEach
void tearDown(TestInfo testInfo) {
    long end = Instant.now().toEpochMilli();
    System.out.println(
        "Class " + getClass().getSimpleName() + " checks folder " + testFolderName +
          " started at " + localTimeFromMilli(start) + " ended at " + localTimeFromMilli(end) +
          ": (" + (end - start) + " ms)");
    //clean up with helper function
    removeTestFolder();
}

Note that this function removes the test folder after each test run. This is enough housekeeping in the serial testing scenarios.

4.2. Multiple Workers for Parallel Test

In a parallel case, we need to ensure that different threads don’t try to create the same folder. We accomplished that by reading the worker ID, set by Gradle in the org.gradle.test.worker system property:

System.getProperty("org.gradle.test.worker", "1")

With this ID, we could make up different folder names for each working thread.

As before, we create four copies of this class. Then, we run the test passing the additional integration tag to ./gradlew:

$ ./gradlew -i cleanTest test -PtestForGradleTag=parallel -PtestForGradleTag=integration | grep "Class TestFolder"

Let’s track the dependency between the test folder name and the worker thread in the output:

We see that during one parallel run with three threads, each class has its own worker ID. However, after the worker pool is exhausted, ID equal to 373 is reused.

5. The Static Horror

Now, let’s examine an example of testing the function that relies on the application’s static state. We’ll use a simple Singleton pattern implementation:

public final class ClassSingleton {
    public String info = "Initial info class";
    private static ClassSingleton INSTANCE;
    private static int count = 0;
    private ClassSingleton() {
    }
    public static ClassSingleton getINSTANCE() {
        return INSTANCE;
    }
    public int getCount() {
        return count;
    }
    public static ClassSingleton getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
        count++;
        return INSTANCE;
    }
    // more features below ...
}

We see the count field, which accumulates how many times the instance of ClassSingleton is requested.

Then, we’ll want to test if this counter is set correctly. So, let’s do that with:

@Test
public void whenOneRequest_thenSuccess() throws InterruptedException {
    ClassSingleton testSingleton = ClassSingleton.getInstance();
    assertEquals(1, testSingleton.getCount());
    Thread.sleep(1000L);
}

This test will fail. Or it will not fail. Or sometimes it fails, and sometimes it doesn’t. Playing with the number of test classes and threads, we can see that it’s simply unpredictable, therefore somewhat useless.

5.1. How to Fix It

This behaviour arises because static variables are defined within the Java Virtual Machine (JVM) scope. Such a virtual machine is started separately for each thread. However, test classes may retake the same thread. So, we can’t expect count to be equal to one if we run the testSingleton() function multiple times.

To make things even worse, we made count a private field and provided no setter for it. Therefore, we have no way to set the singleton state before the test (no matter how much sense it’d make).

Gradle comes to the rescue with the forkEvery property, which says how often the new thread should be started. If we set it to one, each test class will have its own thread and also its own JVM. To set this property, we need to edit the ‘test‘ section in the gradle.build file:

test {
    maxParallelForks = (int) (Runtime.runtime.availableProcessors() / 2 + 1)
    forkEvery = 1
    useJUnitPlatform {
        includeTags testForGradleTag
    }
}

Now our singleton test will always succeed. Moreover, this feature isn’t limited to parallel testing. If we touch on the static context in many test cases, we may also need it in the serial testing scenarios. We only need to locate tests in different classes.

Finally, we should be aware that starting a new JVM for each test class slows down the tests. We can disable this feature by setting forkEvery to 0, which is its default value.

6. Conclusion

In this article, we learned how to run parallel tests in Gradle. First, we configured Gradle for such a task. Then, we examined how the tests are performed. Based on this, we concluded that tests are parallel based on the test class rather than the method.

Next, we took a look at cases that are particularly troublesome in parallel testing. This included access to resources and handling the static state of the tested application. We saw how Gradle mitigated these problems.

Finally, we can regard parallel testing with Gradle as well-suited to speed up independent test runs.

As always, the code for the examples is available over on GitHub.

       

JDBC (Java Database Connectivity) is the foundational API for relational database access in Java, sitting beneath all higher-level abstractions like JPA and Spring Data. Understanding how to connect, query, manage transactions, and handle results at the JDBC level gives us precise control over database interactions and a solid foundation for troubleshooting any data-access layer.

This series covers core JDBC operations from fundamentals to practical patterns, organized by concern: from setting up connections and connection pools, through executing statements and working with result sets, managing schemas and metadata, and diagnosing common errors.

Getting Started with JDBC

• Loading JDBC Drivers
• Jdbc URL Format for Different Databases
• A Comparison Between JPA and JDBC
• A Simple Guide to Connection Pooling in Java
• Best Practices for Sizing the JDBC Connection Pool

Executing Statements

• Batch Processing in JDBC
• A Guide to Auto-Commit in JDBC
• How to Execute Multiple SQL Statements as One in JDBC
• Store File or byte[] as SQL Blob in Java (Store and Load)
• Using “LIKE” Wildcards in Java PreparedStatements
• Inserting Null Into an Integer Column Using JDBC

Working with ResultSets

• Processing JDBC ResultSet With Stream API
• Pagination With JDBC
• Get the Number of Rows in a ResultSet
• Convert ResultSet Into Map
• Converting a JDBC ResultSet to JSON in Java

Connection and Schema Management

• Connecting to a Specific Schema in JDBC
• Extracting Database Metadata Using JDBC
• How to Check if a Database Table Exists with JDBC
• Is java.sql.Connection Thread-Safe?
• Intercept SQL Logging with P6Spy
• Mocking JDBC for Unit Testing

Errors and Troubleshooting

• Fix the Java-MySQL Connection Exception: Public Key Retrieval is not allowed
• Resolving PostgreSQL ERROR: canceling statement due to user request
• Solving “java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver”
• Fix the Exception “Cannot issue data manipulation statements with executeQuery()”
• Tomcat Warning “To Prevent a Memory Leak, the JDBC Driver Has Been Forcibly Unregistered”

       

1. Spring and Java

>> Avoiding Final Field Mutation [inside.java]

JDK 26 starts warning when reflection mutates final fields, which is definitely a quiet but meaningful step toward the JVM actually enforcing what final has always promised.

Also worth reading:

• >> Dockerizing a Java 26 Project with Docker Init [foojay.io]
• >> MCP in the Java World: Bringing Architectural Strategy to LLM Integrations [infoq.com]
• >> Next-Level Observability with OpenTelemetry [jetbrains.com]
• >> Issue 334 – ArrayList vs LinkedList Puzzle [javaspecialists.eu]
• >> Spring AI Recipe: Agentic Planning with TodoWriteTool [linkedin.com]
• >> Maven Plugin for JSpecify.dev Null Restrictions [ik.am]
• >> JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview) [openjdk.org]
• >> JEP 535: Shenandoah GC: Generational Mode by Default [openjdk.org]

Webinars and presentations:

• >> A Java Performance Quest: Taming Unsafe Code, Embracing Idiomatic Style & Debugging the Linux Kernel [infoq.com]
• >> Make Java Safer with Flexible Constructor Bodies – Inside Java Newscast Episode #111 [inside.java]
• >> Reflecting on HAT: A Project Babylon Case Study [inside.java]
• >> A Bootiful Podcast: Ronald Dehuysser, founder of JobRunr, on their ambitious new JavaClaw-like agent runtime [spring.io]
• >> How Netflix Uses Java – 2026 Edition [youtube.com/@java]

Time to upgrade:

• >> A2A Java SDK 1.0.0.Beta1 Released [quarkus.io]
• >> Spring AI 1.0.6, 1.1.5, 2.0.0-M5 Available Now [spring.io]
• >> Spring Shell 4.0.2 is out! [spring.io]
• >> JReleaser reaches 5 [andresalmiray.com]
• >> Oracle Critical Patch Update Advisory — April 2026 [oracle.com]
• >> JDK 25.0.3 Release Notes [oracle.com]
• >> JDK 27 Early-Access Builds [java.net]
• >> Liberica JDK 8u492 / 11.0.31 / 17.0.19 / 21.0.11 / 25.0.3 / 26.01 builds available [bell-sw.com]
• >> Testcontainers for Java 2.0.5 [github.com/testcontainers]
• >> Zuul 3.6.0, 3.6.1, 3.6.2, and 3.5.9 [github.com/Netflix]
• >> Micronaut 4.10.22, 3.10.6, and 3.8.14 [github.com/micronaut-projects]
• >> Camel 4.20.0 and 4.14.7 [github.com/apache]
• >> Grails 7.0.11 [github.com/grails]

2. Technical & Musings

>> Vibing, Harness and OODA loop [event-driven.io]

A sharp framing of why “vibe coding” with LLMs feels productive but often isn’t.

Also worth reading:

• >> ESP32 time bootstrap problem [advancedweb.hu]
• >> Before GitHub [pocoo.org]
• >> Equity for Europeans [pocoo.org]
• >> Thoughts on AI, Databases, and Conferences as of April 2026 [ozar.me]
• >> Structured-Prompt-Driven Development (SPDD) [martinfowler.com]
• >> What’s Missing in the ‘Agentic’ Story [mnot.net]
• >> Responsibility is the Human Moat [satisfice.com]
• >> Scaling Camera File Processing at Netflix [netflixtechblog.com]
• >> The Big Mac Coding Era [dandreamsofcoding.com]

3. Pick of the Week

>> How good engineers write bad code at big companies [seangoedecke.com]

       

IntelliJ IDEA is the leading IDE for Java and JVM development, combining intelligent code analysis, deep framework integration, and powerful tooling into a single environment. From quick-fixes and refactoring to remote debugging and plugin development, mastering IntelliJ means spending less time on tooling and more on solving actual problems.

This series covers practical IntelliJ IDEA workflows from setup to advanced development, organized by task: from configuring the IDE and managing projects, through coding productivity features, debugging applications locally and remotely, and navigating codebases with built-in analysis tools.

IDE Setup and Configuration

• How to Set Up Environment Variables in IntelliJ IDEA
• Decreasing IntelliJ RAM Usage
• Increase the Memory Size Limit on IntelliJ IDEA
• IntelliJ IDEA vs Eclipse – Key Feature Differences
• How to Set JVM Arguments in IntelliJ IDEA?
• What Is the .idea Directory?

Project and Build Management

• How to Change the Java Version in an IntelliJ Project
• Add External JAR File to IntelliJ Project
• IntelliJ – Cannot Resolve Spring Boot Configuration Properties Error
• Converting a Java Project/Module Into a Maven Project/Module in IntelliJ IDEA
• Intellij Idea – How to Build Project Automatically

Coding and Editing

• Disable Wildcard Import in IntelliJ
• Fix “Command Line is Too Long” in IntelliJ
• Common Shortcuts in IntelliJ IDEA
• How to Stop or Limit Indexing in Intellij IDEA
• JetBrains @Contract Annotation
• An Introduction to Refactoring with IntelliJ IDEA
• Auto-import Classes in IntelliJ

Debugging

• Debugging Spring Boot Applications With IntelliJ IDEA
• Remote Debugging with IntelliJ IDEA
• IntelliJ Debugging Tricks
• Debugging an Application Running in Docker With IntelliJ IDEA
• Debugging Java Streams with IntelliJ

Code Analysis and Navigation

• Connect to Database Through Intellij Data Sources and Drivers
• Decompiling Classes in Java
• How to Count Lines of Java Code Using IntelliJ IDEA?
• Writing IntelliJ IDEA Plugins
• Open Multiple Projects in the Same Window in IntelliJ IDEA
• Git Integration in IntelliJ IDEA

       

Jakarta EE (formerly Java EE) is the standard enterprise Java platform, providing a comprehensive set of specifications for building scalable, multi-tier server-side applications. It covers the full stack from web tier components like Servlets and JSP to enterprise services like CDI and EJB, along with robust support for RESTful and SOAP web services.

This series covers core Jakarta EE APIs in practical application, organized by concern: from setting up and deploying applications on Jakarta EE servers, through building the web tier with servlets and view technologies, designing service layers with JAX-RS and JAX-WS, enforcing contracts with Bean Validation, and managing enterprise components with CDI and EJB.

Jakarta EE Platform and Core Concepts

• How to Deploy a WAR File to Tomcat
• Migrate From Java EE to Jakarta EE
• Java Naming and Directory Interface Overview
• Java EE vs J2EE vs Jakarta EE
• Web and Application Servers for Java
• Jakarta EE 10

Servlets

• Introduction to Java Servlets
• Handling Cookies and a Session in a Java Servlet
• Introduction to Servlets and Servlet Containers
• How to Register a Servlet in Java
• Servlet Redirect vs Forward
• Returning a JSON Response from a Servlet
• Jakarta EE Servlet Exception Handling

JSP and JSF

• Guide to JavaServer Pages (JSP)
• Introduction to Primefaces
• A Guide to the JSTL Library
• An MVC Example with Servlets and JSP
• Introduction to JSF EL 2

Web Services: JAX-RS and JAX-WS

• Consume a SOAP Web Service in Java
• JAX-RS is just an API!
• Introduction to JAX-WS
• Introduction to Apache CXF
• JAX-RS Client with Jersey
• Jersey Filters and Interceptors
• Server-Sent Events (SSE) in JAX-RS
• Set a Response Body in JAX-RS

Bean Validation

• Java Bean Validation Basics
• Difference Between @NotNull, @NotEmpty, and @NotBlank Constraints in Bean Validation
• Validations for Enum Types
• Grouping Jakarta (Javax) Validation Constraints
• Method Constraints with Bean Validation 3.0
• @Valid Annotation on Child Objects
• Java Validation List Annotations
• Validating Container Elements with Jakarta Bean Validation 3.0

CDI and EJB

• An Introduction to CDI (Contexts and Dependency Injection) in Java
• Guide to EJB Set-up
• Guide to Jakarta EE JTA
• A Guide to Message Driven Beans in EJB
• Singleton Session Bean in Jakarta EE
• Introduction to the Event Notification Model in CDI 2.0
• Java EE Session Beans