Advanced Kafka probe configuration in JProfiler

In our first Kafka screencast, we looked at how JProfiler correlates message flow and CPU usage through producers, consumers, and topic-level call trees.

In this follow-up, we go deeper, showing how to configure custom naming for Kafka messages based on their content.

This enables you to:

• split call trees by semantic message types
• track specific event types in probe views
• add value-level details to single event descriptions
• visualize outliers in event duration histograms

We also trigger a Kafka message spike via an API call and analyze its impact, all without changing the application code.

Profiling Kafka #1 – Message Flow & Hot Spots

Kafka-based applications are notoriously hard to profile. Message flow happens in background threads, stack traces don’t reveal the full picture, and it’s hard to know which topic contributes to which hot spot.

JProfiler’s Kafka probes give you deep insight—producers, consumers, and message-level details are all captured and correlated with performance data.

This screencast walks through profiling a Spring Kafka application, showing how:

• consumer call trees are split by topic
• producers link directly into probe views
• you can correlate CPU hot spots with Kafka topics
• Kafka events are filterable, inspectable, and aggregatable

Bringing JProfiler to VS Code with Kotlin Multi-Platform

At ej-technologies, we've long provided JProfiler integrations for Java IDEs like IntelliJ, Eclipse, and NetBeans. These plugins share a significant amount of logic—profiler configuration, session management, and communication with the JProfiler backend—all written in Kotlin.

When we decided to add support for VS Code, we faced a problem: VS Code extensions run on Node.js, not the JVM. Rewriting the plugin from scratch in TypeScript would have been inefficient. Instead, we turned to Kotlin Multi-Platform (KMP), allowing us to reuse our existing Kotlin code while adapting to the JavaScript ecosystem.

Caching auto-provisioned install4j distributions in CI pipelines

Starting with install4j 11.0, integrating install4j into your build system has become much easier: The Gradle, Maven, and Ant plugins can now auto-provision the install4j distribution. This means the plugins will download and cache the appropriate install4j version automatically, so you no longer need to install install4j manually.

Cross-platform JRE bundle creation under threat from JEP 493

One of the most valuable capabilities introduced with the Java module system in Java 9 is its support for creating custom runtime images with jlink. Developers can include only the modules they need, resulting in lightweight JRE bundles tailored to the requirements of their applications. Using the --module-path option, it has even been possible to generate those runtime images for different operating systems from a single host machine.

With Java 24, JEP 493 introduces a change that significantly impacts this workflow. JDK vendors can now configure builds without .jmod files, as jlink can optionally extract the required resources from the lib/modules jimage file. While this change reduces the size of the JDK by about 25%, it also removes critical support for cross-platform linking.

Improvements for macOS App Store submissions in install4j 11.0.2

install4j 11.0.2 introduces several new features to simplify macOS App Store submissions, including automated entitlement handling for TestFlight, improved support for local testing with development provisioning profiles, and dynamic bundle versioning for easier resubmission of builds.

Refreshed JProfiler IDEA plugin for the new UI

Kotlin 2.0 features a total rewrite of the Kotlin compiler known as "Kotlin K2". IntelliJ IDEA will remove support for the old compiler in version 2024.3 impacting all plugins that depend on the Kotlin plugin, such as the JProfiler IDEA plugin.

The newest version of the JProfiler IDEA plugin for IntelliJ IDEA now includes support for Kotlin K2 mode. This means that the JProfiler plugin no longer prevents switching to K2 mode in IntelliJ IDEA 2024.2 and is now ready for IntelliJ IDEA 2024.3 where K2 mode will be the default and plugins depending on the old API will no longer be loaded.

We took this opportunity to align the JProfiler plugin with another recent major change in IntelliJ IDEA: The new UI, which became the default in IntelliJ IDEA 2024.2. It is impractical for IDEA plugins to support both the old and the new UI, so we decided to change the UI once the new UI became widely used.

Migrating to install4j 11.0

In most cases, migrating to install4j 11 involves simply opening and saving your project with the install4j 11 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

Namespace awareness of XML actions in install4j

This post explains an exceptional backward-incompatibility in the install4j 10.0.9 release. This was necessary due to a change in install4j 10.0.8 that was intended to fix the corruption of namespaced XML documents by modifying XML actions.

Why JVMTI sampling is better than async sampling on modern JVMs

In recent years, "async sampling" has been hyped as a better way of CPU profiling on the JVM. While this has been true for some time, it is no longer the case. This blog post explains the history of sampling and the current state of the art.