Today we’re excited to make available an early version of a Java-based client API for MQ Light. While this API shares similarities with our Node.js client we’ve also set our sights on creating a truly asynchronous API that’s ideal for wiring together the components comprising a reactive system. Right now, you can download a .zip from this page that contains the client, documentation and also sample code. Or if you’re just browsing: the Javadoc is also available here.

The MQ Light messaging model underpinning the Java client emphasises simplicity and the speed with which it can be used to solve common problems. The same model is used by all of the other MQ Light clients. Another point of commonality is support for a carefully selected set of message payloads. All of the MQ Light language clients support exchanging: text, binary, and JSON data – making it straight forward to wire together components written in a variety of different languages.

Another key design point for the Java API – is that *nothing* should block. The client does all of its work either on the thread calling into client code – or on a small number of pooled threads used to carry out specific functions (such as network I/O – more on this later!). This fits well with the asynchronous nature of messaging and also has the benefit of reducing the number of thread context switches required to send a message. We’ve also been keeping one eye on how frameworks like Akka are taking an actor-based approach to concurrency and have built the Java client to be straightforward to encapsulate as an actor.

While on the subject of framework integration: isn’t it annoying when a library looks great, but doesn’t quite integrate with the other components you’ve chosen to use? That annoys us too, which is why we’ve built the Java client in a modular way. Here’s how all the pluggable parts of the Java client fit together:

By default the client uses Logback to implement the SL4J logging interfaces, Netty to implement network I/O, with standard Java Executor classes backing the other components. But say you want to use a different network library? No problem: just write a few lines of shim code implementing the relevant Java interfaces, and away you go!

As always – we’re keen to hear from you. So if you have any question, or have tried the Java client and want to give us feedback – head on over to the forum.

7 comments on"Introducing: an MQ Light client for Java"

  1. Hi All, Is there a way for a client re-connecting feature when IBM MQ queue manager got fail-over from one node to other when using Multi-Instance setup.

  2. Hi, any idea when the Java-based client API for MQ Light will GA? thanks.

    • LaurenceBonney April 14, 2015

      Hi Eva, the vague answer is ‘shortly’. We are finalising documentation and will make an updated version of the MQ Light Java client code available with the same licence as the node.js client. We do not have a hard date for GA, tentatively I would anticipate it being within weeks rather than months.


    • LaurenceBonney May 22, 2015

      Hi Eva, we got there in the end! The MQ Light Java client is now GA and available on the Maven Central repository for download, links also available via the MQ Light downloads page.

  3. Is there a way to access a local (not Bluemix) instance of MQ Light via JMS API? I ask because the only documented JMS code I’ve seen assumes a Bluemix deployment.

    • Rob Nicholson February 13, 2015

      Hi Chris. There is no supported way to do this today. In Bluemix JMS runs over the MQ proprietary wire protocol MQFAP and this is not available in MQ Light stand alone. We heard from forum users that it is possible to use the open source Apache Qpid implementation of JMS with MQ Light over AMQP 1.0.

      We would be very interested to hear people’s opinions on using JMS with MQ Light. We’ve certainly had feedback that people wanted a non blocking java API as described here but is JMS also needed?

Join The Discussion

Your email address will not be published.