Embed Apache Johnzon in your library to not depend on a dependency

Sometimes you need to parse JSON files in a library. Then the question is pretty quickly: do I use a SPI (Service Provider Interface) to let the user choose the library he uses with my code or do I bind my library to one parser/writer?

Sometimes the answer is easy: when the need is basic (read/write) having a SPI and a default implementation is pretty good and let your users avoid to depend on one implementation. Said otherwise, you let your users reuse the implementation they probably already have in their application/classpath.

However sometimes you need a more advanced setup to get some customizations or features (like comments in JSON for instance which is very handy for configuration files) so either you bind your library to one implementation and your users end with N JSON implementations they don’t control and which potentially conflict together, or you enhance a lot your SPI risking to loose some features if your user chooses an implementation not supporting some of your needs, or you can also grab an implementation which work fine for you and just put it in your delivery. This last option is pretty nice cause then your code can use all the shortcuts an implementation can offer – like custom annotations.

Going further with this last option you can also potentially reuse some standard API like JSON-P or the coming JSON-B in your code and just hide it and not depend on the container for the runtime.

Of course there is no free lunch and it will make your delivery a bit more heavy but a good mapper is ~200k max so it is still a good option for JSON needs.

How to do it?

Continue reading

BatchEE: avoid CDI integration issues

If you use BatchEE as JBatch implementation with a EE container which doesn’t integrate directly with it you can get some surprises like not using the right bean manager or just getting errors about CDI context.

This is because by default BatchEE uses its own pool of threads as needed by the spec but then in these threads CDI is not initialized and the lazy lookup of the bean manager done by BatchEE to avoid to use a “startup” bean manager at runtime in some – expensive – containers can fail cause of it.

Continue reading

@CacheResult: JCache + CDI to the rescue of microservices?

JCache API comes with several built in interceptors for CDI making its usage decoupled from the cache API itself and more user friendly.

Let’s have a look to this API.

CacheResult: the method execution killer

Probable one of the most common use cache is to avoid to pay the cost of a method each time you call it.

Reasons can be as different as:

  • Computation done by the method is expensive
  • The method contacts a remote service and you want to cut off the implied latency
  • The method accesses a rate limited resource
  • ….

In this cache @CacheResult brings a nice and easy to setup solution. Simply decorating the method with @CacheResult you will avoid the actual method invocation after the first call and while it is cached.

Basic usage

Here a sample using a service simulating a slow method:

Continue reading

Loggers integrations love method reference (java 8)

Integrating loggers with some frameworks sometimes requires to wire some stream (OutputStream typically) to the logger itself.

Most of the time you pass to your “LoggerOutputStream” a Logger instance and a Level – or you have some condition in the implementation to select the level.

This is not a hard task but for some loggers you need a big switch to handle the level. Code is quite noisy for pretty much nothing.

With Java 8 the implementation is pretty simple, just use a method reference and that is it!

Nice thing is you can automatically type it “Consumer<String>.

Here is a sample with maven Log API:

import java.io.IOException;
import java.io.OutputStream;
import java.util.function.Consumer;

import static java.util.Optional.of;

public class LoggerOutputStream extends OutputStream {
    private static final int BUFFER_SIZE = 1024;

    private byte[] buffer;
    private int count;
    private int bufferLen;

    private final Consumer<String> log;

    public LoggerOutputStream(final Consumer<String> log) {
        this.log = log;
        this.bufferLen = BUFFER_SIZE;
        this.buffer = new byte[bufferLen];
        this.count = 0;

    public void write(final int b) throws IOException {
        if (b == 0 || b == '\n') {

        if (count == bufferLen) {
            final byte[] newBuf = new byte[bufferLen + BUFFER_SIZE];
            System.arraycopy(buffer, 0, newBuf, 0, bufferLen);
            buffer = newBuf;
            bufferLen = newBuf.length;

        buffer[count] = (byte) b;

    public void flush() {
        of(count).filter(c -> c > 0).ifPresent(c -> {
            log.accept(new String(buffer, 0, c));
            count = 0;

    public void close() {

And the usage is then pretty simple as well:

// getLog() is available in a Mojo = maven plugin
OutputStream out = new LoggerOutputStream(getLog()::info);

The interesting part is a bit hidden but you need to look for the method ref usage (log.accept(new String(buffer, 0, c));) where actually without it you would get a big switch to handle it so it is a nice win regarding the simplicity of the code and its evolutivity!

Simple JAX-RS resource to match Can.JS defaults

Can.JS is a nice client side (javascript) library providing a MVC solution out of the box. The model is often backed by some JSON server and in Java(EE) case by JAX-RS.

Can.JS has a shortcut for CRUD models called ‘resource’ based on a default mapping. Let see how to implement it on a Java server side easily.

Continue reading