Implicit converters for MicroProfile Config

Last month (January 2018), an update of the MicroProfile Config specification, version 1.2, was released which makes it easier to convert the configuration values to class instances.

It adds the concept of implicit/automatic converters and removes the requirement for creating specific converters in many cases.

The first implementations are already available and Atbash Configuration is now also updated.

This blog describes what the implicit/automatic converters are and how you can use them.

The configuration values we define are Strings because they are defined as a set of Characters in the configuration files. Using the configuration could be limited to a system which is capable of reading those Strings and that the developers need to convert these values to the proper instance (like Integer, Boolean or application specific classes) themselves.

But in that case, each developer will write his own set of converters and in the case of Integers and Booleans, for example, they are all the same.

So the framework itself can take care of these converters. And since we have then already the concept of a convert, it is easy to foresee an SPI which allows the creation of custom Converters by the developer for their application specific classes.

These basic converters for Integer and Boolean for example where present since the first release of the spec. Just as the SPI to add your own converters.

But the creation of all those custom converters can be minimized further. Since our application specific classes can be created from a String, they probably have some means of instantiating them through a method which takes a String parameter

– The constructor

– A static method with names like valueOf or parse.

So with the new implicit/automatic converters feature, when we have some class like this

public class ClassWithStringConstructor {
    private String value;

    public ClassWithStringConstructor (String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }
}

and have a parameter

some.key = Atbash

We can retrieve an instance of the class, with the value using

config.getValue("some.key", ClassWithStringConstructor.class)

or when we are in a CDI enabled context, we can also use injection

@Inject
@ConfigProperty("some.key")
private ClassWithStringConstructor parameterValue;

Collection type parameters

Another nice addition to this 1.2 release, is the use of collection type parameters. The ability to have multiple parameter values, like a list of values which is converted to an Array, List or Set.

It is quite common that a configuration value is, in fact, a list of value.

pets = dog,cat

previously, the developer needed to split the String and use the individual parts separately (although this is a very simple task with String.split() ), can be done automatically.

config.getValue("pets", String[].class)

With injection, we can automatically convert it to a List or a Set.

@Inject
@ConfigProperty(name = "pets")
private List<String> pets;

The List and Set variants can’t be used in a programmatic way (using config.getValue) since the second parameter doesn’t accept parameterized types (like List<String>).

When you have a value which contains a comma it in, you need to escape it

a,b,c\\,d

which results in 3 configuration values, where the last one is c,d.

We can even combine the collection type feature with the implicit/automatic converter feature. If we instead specify the class name like ClassWithStringConstructor instead of String, the configuration framework will use the appropriate way of converting.

config.getValue("pets", ClassWithStringConstructor[].class)

or

@Inject
@ConfigProperty(name = "pets")
private List<ClassWithStringConstructor> pets;

Octopus Config

As you could read in a previous blog, Octopus Config is a Java 7 port from Geronimo config. The support for the implicit/automatic converters and collections (like the arrays, List, and set) is taken from them.

Octopus Config itself is also updated so that the YAML usage supports the Collection type parameters. The example above with the pets can be written in the YAML equivalent format as

pets: [dog , cat]

The release 0.9.1 contains also some small other features are listed here. Most notable features are

– Improved Class converters based on different classloaders.

– Test artefact.

– Logging in Java SE environment

– Improvement information in logging with @ModuleConfigName

– Compatibility with another MicroProfile Config implementation on Java 8.

With the addition of the implicit/automatic converters, the need for writing custom converters can be dropped and conversion will take place by convention.

The Octopus Config version v0.9.1 is updated to incorporate these features together with some small other improvements and fixes.