encoding in jdk openj9 docker images

Recently I was looking into encoding problems and I was really surprised to find this:

docker run –rm adoptopenjdk/openjdk11-openj9:jre- java -XshowSettings 2>&1 | grep encoding

file.encoding = ANSI_X3.4-1968
file.encoding.pkg = sun.io
ibm.system.encoding = ANSI_X3.4-1968
os.encoding = ANSI_X3.4-1968
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = ANSI_X3.4-1968

Even adding environment variables like LC_ALL or LANG did not help ūüôĀ

docker run –rm -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 adoptopenjdk/openjdk11-openj9:jre- java -XshowSettings 2>&1 | grep encoding

But the issue was fixed with a more recent version of the image:

docker run –rm adoptopenjdk/openjdk11-openj9:jre-11.0.6_10_openj9-0.18.1-alpine java -XshowSettings 2>&1 | grep encoding

file.encoding = UTF-8
file.encoding.pkg = sun.io
ibm.system.encoding = UTF-8
os.encoding = UTF-8
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = UTF-8

Be aware of this insides of the images you use!

Happy coding

fault tolerance for jax-ws with resilience4j

In a recent project, we still have to use SOAP webservices and I wanted to apply some resilience pattern such as retry to my project.
Also a collegue just presented a java library called resilience4j so I wanted to use that one.

Of course, there are a lot of other possibilites like using other libraries (like Hystrix) or applying the sidecar pattern outside of my application in a cluster.

As you can see in the documentation, resilience4j is build for functional programming style and it supports some functional interfaces
which can be decorated to apply the retry mechanism to the function invocation. In the examples, you can always find a simple setup to pass the supplier and decorate it only for the particular method.

In my use case, I do not want to write the decoration code for each and every method (or function). I have a third party WSDL, generated the webservice interface and port via wsimport and now I want to generically apply the retry mechanism to the webservice client. But my solution is not very complicated, it is using a reflection proxy and invocation handler to direcly decorate and execute the method via the Retry classes.

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
import io.github.resilience4j.retry.Retry;
public final class WebserviceFactory{
static <T> T decorateWithRetryer(final T service, Retry retry) {
InvocationHandler invocationHandler = (proxy, method, args) -> retry.executeCheckedSupplier(() -> method.invoke(service, args));
return (T) Proxy.newProxyInstance(service.getClass().getClassLoader(),
service.getClass().getInterfaces(), invocationHandler);

This way I am able to decorate my whole service interface.

One note I can make regarding the exception handling: In case of an exception, an InvocationTargetException is thrown. If you want to have the target one, you have to unwrap it.

The source code of my example is available at https://github.com/mwiede/jaxws-resilience4j.

Memory Footprints of hello-world microservices

I was curious reading about openj9 as a JVM being high performance and using a low memory footprint. I was working in a project, where the environment of software systems consisted of around 30 Java Applications, a few running on tomcat, a few on weblogic and the most running on dropwizard microservice framework. The desirable goal for every developer was to start the complete platform on his local notebook and therefor a virtalbox image was build using vagrant. As there were so many applications, each microservice itself consumed around 250MB of RAM and with the number of services growing we already hit 24GB image size of the virtualbox image. I found the blogpost https://codeburst.io/microservices-in-java-never-a7f3a2540dbb which describes the same issue and that if you those java microsevices in a cloud infrastructure, you would even have to pay even more money only because of the memory footprint.

Luckily there was somebody doing a comparsion of openj9 vs hotspot VM in his two blogpots https://royvanrijn.com/blog/2018/05/openj9-jvm-shootout/ and https://royvanrijn.com/blog/2018/05/openj9-hotsport-specjvm2008/ already. He was is showing some benchmarks and results.

My own simple comparison

I tested it on my own (just for curiosity) and came to the same result. In terms of memory consumption, there is a potential improvement with openj9 as JVM alternative.

I picked three helloworld examples using maven archetypes from dropwizard, helidon and Spring Boot.

First I packacked them into docker images using adoptopenjdk/openjdk8-openj9:alpine-slim on the one hand and adoptopenjdk/openjdk8:alpine-slim on the other hand.

Then I compared memory consumption using application metrics and dockers stats and could have a rough idea of the differences. Here is the result of the dropwizard app:

openj9 without any parameters to the jvm:

  • jvm.memory.heap.used = 10563328 B, jvm.memory.total.used = 37838048
  • docker container = 48.55MiB

hotspot without any parameters to the jvm:

  • jvm.memory.heap.used = 28511520 B, jvm.memory.total.used = 61381328
  • docker container = 118.3MiB


Whether you have the goal of running your complete software on your developer laptop or you want to save money running your services in a public cloud, openj9 provides a possibility to reduce the memory footprint of your java application by around 50%.

As it was mentioned in the other blog posts, there are also a few downsides with this, but if you test everything and the requirements (in terms of computation performance) are met, you should give it a try.