/
Choice of message bus

Choice of message bus

This is the rationale behind our choice of ActiveMQ as messaging software

We have chosen ActiveMQ as messaging software for the pilot, for the following reasons

  • It's easy to set up

  • It seems to support every feature we have requested till now

  • Its widely used

  • It supports SSL encrypted communication

  • There is wide language support: Java (JMS 1.1), C, C++, C#/.Net (NMS...), JavaScript - Ajax or WebSockets, Perl, PHP, Python and more

  • There is wide support for messaging protocols: OpenWire, REST, Stomp, WS Notification, XMPP, AMQP.

  • There is persistence support

  • Clustering is supported (Active/Fallback)

ActiveMQ is *not* an Enterprise Service Bus, but a messaging provider. Till now we have not met any need for more than basic messaging in terms of queues and topics.

Migration

Following several years of production use, we are now planning a migration from ActiveMQ Classic to ActiveMQ Artemis as part of the ongoing Java platform upgrade.

Why migrate?

The primary driver is Java version compatibility. ActiveMQ Classic supports Java up to and including version 23. The Java SecurityManager API — which Classic relies on internally — was deprecated in Java 17 and removed in Java 25. Classic has not addressed this, which means it represents a hard ceiling on our Java upgrade path.

ActiveMQ Artemis resolved this in version 2.44.0 (November 2025) by introducing a multi-release JAR with separate implementations for Java 17–23 and Java 24+. Artemis therefore supports Java 25, making it compatible with our intended Java migration target.

What Artemis offers compared to Classic

Artemis preserves all the properties that originally motivated our choice of ActiveMQ Classic, and improves on several of them:

  • Easy to set up — configuration is consolidated in a single broker.xml file

  • Queues and topics — fully supported; Artemis uses an address model where anycast routing corresponds to queues and multicast routing corresponds to topics

  • Wide protocol support — AMQP (now fully native), OpenWire, STOMP, MQTT, and WebSocket

  • SSL encrypted communication — supported

  • Persistence — Artemis uses its own high-performance append-only journal with async disk writes, replacing Classic's KahaDB

  • Clustering — supported (live/backup pairs, as well as cluster topologies)

  • JMS compatibility — the standard javax.jms / jakarta.jms API is unchanged; client code requires minimal modification

What changes

The internal broker architecture is different. Artemis is built on Netty NIO, meaning it uses non-blocking I/O rather than one thread per client connection. This improves scalability significantly but is transparent to application code.

The broker configuration format changes from activemq.xml to broker.xml. Destination definitions, security settings, and address policies must be translated.

Artemis requires Java 17 as a minimum (Java 11 support was dropped when Artemis moved from an embedded Jetty 10 to Jetty 12, which requires Java 17).

Conclusion

Artemis is not a replacement product — it is the natural continuation of ActiveMQ, now developed under its own Apache project. It retains all the messaging capabilities that have served us well since ActiveMQ was chosen, while removing the Java version ceiling that would otherwise block our platform upgrade.