AtomicJar, Inc. is pleased to announce the release of Testcontainers-Java 1.16.0! This is the first release sponsored by AtomicJar since our launch.
And, while this is not a “big bang major release” (yet 😉 ), it was a great opportunity for us to focus on stability and ensure that your Testcontainers-based tests not only run as smoothly as possible but also on as many platforms as possible.
Better Apple M1 compatibility
New M1-based Apple laptops are great! In fact, we use them as well 🙂 And, while we cannot magically solve the problem with x86 images and rely on Docker, we took the opportunity to at least try to fall back to QEMU-based handling of them in Docker.
Now, if you are using an image that only supports the x86 architecture, Testcontainers will force its usage, and Docker for Mac will therefore attempt to use QEMU to run it. We tested this with a few representative images (such as MySQL) and it worked great. As always, we provide as many workarounds as possible so that you don’t have to think about the challenges of running Docker-based test dependencies 🙂
P.S. We also resolved the ambiguity of the JNA dependency version – now it comes directly from docker-java, as we no longer depend on Visible Assertions.
New default transport
Testcontainers relies on https://github.com/docker-java/docker-java – an OSS Docker API client (that we also maintain now). But with Testcontainers, we were always ahead in terms of transport: When docker-java was defaulting to Jersey, we were using Netty and we were also one of the first projects to shade Netty.
Why shading, btw? Because Testcontainers is a very generic library, used with thousands of technologies, and bringing a lot of dependencies with us would make your lives much harder. This is why we shade every dependency that is not present in our public API.
I love updating dependencies and solving conflicts!
Nobody ever
But, while Netty is a great and super performant library, we were lacking some features (such as Windows Npipe support). And in addition, overall it didn’t feel right to use Netty while we only needed a simple HTTP client. This is why we created a transport for docker-java based on OkHttp that brought with it support for Npipes and a lot of other improvements. Not to mention that it was much easier to shade it, as it does not depend on native libraries (which is exactly what makes Netty super fast!).
We introduced OkHttp as an optional transport in Testcontainers (and later contributed it to docker-java), while Netty remained the default option, and we later inverted the logic so that OkHttp has become the default while keeping Netty as an option in case of any potential regressions. Shortly after, we dropped Netty completely, as there were none and nobody even noticed the migration (except those who were having issues with Netty, of course).
OkHttp served us great for the time being – it was a very lightweight HTTP client, with Okio (also maintained by Square) being the only dependency. But, starting with OkHttp 4.0, it has a Kotlin dependency (as the majority of its users are Android developers, and it makes a lot of sense for them). Since we were not ready to have Kotlin as a dependency, nor to shade it, we started experimenting with the freshly released Apache HttpClient5.
The fifth version of that well-known library was a major step forward and brought a lot of flexibility and options that were missing in HttpClient4 back when we considered alternatives to Netty. Unlike the OkHttp implementation, we contributed the Apache HttpClient5-based transport directly to docker-java, where we did extensive testing of it using docker-java’s own test suite and later added it to Testcontainers as an alternative option.
Now, a year later, we’re happy to switch to the HttpClient5-based transport by default. Not only does it fix some issues, but it also comes as a pre-shaded dependency from docker-java (the so-called “zerodep” transport).
Let us know if you have any trouble with it and be aware that OkHttp is still available if you set transport.type = okhttp in $HOME/.testcontainers.properties.
Windows improvements
For us at AtomicJar, Windows is a first-class citizen as a development environment. Therefore, we strive to provide a great user experience for our products, as well as for Testcontainers itself, on Windows. Since the development of Docker for Windows is moving ahead with high speed and is constantly introducing exciting new features, such as the new WSL2 backend for Docker, we want to make sure that developers using Testcontainers can get into a great flow, without having to rely on platform-specific workarounds.
In this new release, we spent some extra time to polish the Testcontainers stability using Docker for Windows, while simultaneously also improving the stability of container startups for all other platforms. Gone are the times, where you had to restart Docker for Windows, or maybe even delete and recreate your virtual network interfaces, only because you wanted to run your integration tests. And Testcontainers works with Docker for Windows from Java processes running natively on Windows, as well as to those running inside WSL2. So no matter your development preferences on Windows, Testcontainers has got you covered!
There is more!
As any other release, Testcontainers 1.16.0 includes many other small but impactful changes, and while some of you may not get excited to learn that e.g. one can now set docker.host in $HOME/.testcontainers.properties, others may find it as a big relief! Or some “behind the scenes” fixes, such as the removal of the “publish all” flag. Recent changes in Docker made containers with many published ports start quite slow, and we didn’t want you to have to wait for a fix in Docker itself.
Please check out the Release Notes for more information about these and other changes in this release.
Thank you to the community contributors to this release, as well as to the AtomicJar team who worked on the release: Richard North, Sergei Egorov, Kevin Wittek, and Piotr Przybył.
You can also join the discussion on GitHub or on Slack with any comments.
We look forward to many more improvements to Testcontainers, as well as revealing more of what we’re working on in the future!
