James Crawford

Edited to add Postscript section after feedback.

Introduction​

In the article about Jactl Continuations and Virtual Threads in Java 8, I discussed the continuation-based mechanism that Jactl uses to support blocking operations in Java versions that don't support Virtual Threads. The continuation mechanism provides support for suspending a script performing a long-running operation, and then resuming it once the operation completes, exactly where it left off, all without blocking the event-loop thread.

As far as the script writer is concerned, they do not need to know whether an operation is a blocking one or not. Jactl provides a Virtual Thread-like way for scripts to have perfectly natural code without needing to be concerned about async/await or other async programming mechanisms like Futures, Promises, or callbacks.

The article also provided a benchmark showing the performance impact of suspending and resuming scripts when running on Vert.x event-loop threads. Jactl provides a way to disable this mechanism for applications running on more modern versions of Java and wanting to take advantage of the built-in Virtual Threads in Java. I wanted to compare the performance of the two approaches.

This article showcases a new benchmark that compares the Jactl/Vert.x approach with Jactl/Virtual Threads and presents the results from running on both Java 21 and Java 25.

Introduction​

Jactl is a secure, embeddable scripting language for Java applications. When I first started developing Jactl, I wanted a scripting language that compiled to bytecode for optimum performance, was secure so applications could control exactly what scripts could and couldn't do, and most of all, did not block the execution thread when long-running, blocking operations were performed.

camel-jactl is a new Apache Camel language module that lets you use Jactl as the scripting language inside Camel for things such as filter predicates, content-based routing rules, and message transformations.

It is available in Apache Camel version 4.22 and later.

It registers itself through Camel's Language SPI under the name jactl.

import static io.jactl.camel.JactlLanguage.jactl;

from("direct:orders")
    .filter(jactl("body.amount > 100 && body.status == 'NEW'"))
    .to("direct:big-orders");

// Or via the Language SPI:
Language jactl = camelContext.resolveLanguage("jactl");
Predicate p    = jactl.createPredicate("body.age > 20");
Expression e   = jactl.createExpression("'Hello ' + body.name");

This post uses JMH benchmarks to compare the performance of Jactl against Camel's built-in Simple language and against Groovy (via camel-groovy) in the places where scripting languages typically appear in Camel applications, from single predicate evaluations up to a complete order-processing route, with a plain-Java route as the no-scripting baseline.

This post presents the results of some representative benchmarks using the JMH benchmarking library to run comparative tests across the following five different Java-based scripting/expression languages:

Benchmarks were run on a Java 25.0.2 JVM

The benchmarks focus mostly on short, expression based tests, in an attempt to mirror the types of scenarios where scripting languages are often used (for example in rules processing systems). There is one longer benchmark with a script of around 30 lines, as well as benchmarks comparing the compilation speeds.

Jactl 2.9.0 is a new release with a focus on performance improvements and bug fixes.

The biggest enhancement in Jactl 2.9.0 is support for the JVM InvokeDynamic instruction which makes invocation of methods on untyped objects almost as fast as invoking methods on typed objects.

Jactl 2.8.0 is a new release with enhancements, bug fixes, and performance improvements.

It adds a new for-in loop statement with pattern matching and destructuring and has many performance improvements, mostly relating to compilation speed and has been benchmarked at compilation speeds of over 300K lines/s.

Edited: Updated with benchmark results from Jactl 2.8.0

Introduction​

Java applications often choose to use an embedded scripting language for reasons including the following:

• to provide a powerful customisation mechanism for users
• to be able to change runtime behaviour without rebuilding/redeploying the application
• for providing business rules/logic
• per-tenant configuration for multi-tenant applications
• rapid prototyping for new features

When selecting a JVM scripting language there are many options to choose from including Jactl, Groovy, Jython (Python), JRuby (Ruby), JavaScript, and Lua. Out of these, Groovy is probably the most widely used scripting language for Java applications. This article compares Jactl and Groovy in order to show their strengths and weaknesses and when you might choose to use one over the other.

Jactl 2.4.0 is a new release with enhancements and bug fixes.

This release provides new date/time classes and also adds the ability to extend the language with new built-in types.

Jactl 2.3.0 is a new release with enhancements and bug fixes.

Due to a missing announcement for release 2.2.0, this release note includes enhancements and bug fixes that were done in 2.2.0 and in 2.3.0.

Jactl 2.1.0 is a new release with a handful of enhancements and bug fixes, as well as a brand new IntelliJ plugin.