Language selector

Java

Spoiler alert: this is a “from zero to hero” session. Assuming you’re familiar with programming (hopefully in Java), after this session you should be able to explain why Testcontainers are needed, simple and powerful 😉

The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies.

Hey, there are two major Java versions released every year! We don’t have to wait 3 years or so for new features anymore. Isn’t that cool? 😉

Java was supposed “to be slow”. However, Java turns out to evolve so fast, that next releases aren’t just version bumps, but might significantly change the rules of the game. That’s a good reason to check out what’s new in Java.

To name a few changes:

Let me start this entry with a dad joke.

Simplified atom model

An electron rides a motorcycle. Suddenly, a police officer stops the electron and says:

‘I had to stop you, because you were speeding, driving exactly 178 and half kilometres per hour.’

‘Well, THANK YOU VERY MUCH, officer!’ the electron says, ‘Now I have absolutely no idea where I am!!!’

Some dad jokes are terrible, and don’t worry if you don’t get this one. It boils down to the uncertainty principle. In extremely oversimplified version: some things in the universe can’t be observed in all their aspects. If you have an apple, you can measure it’s mass, volume, size, (and if falls on your head) velocity, all at the same time. Without affecting the apple itself.
However, if you’re interested in electrons, the more accurately you know its speed, the less you know its location, and vice versa, hence atomic orbital. (Gosh, will atomic things stop chasing me? 😅)

Hey, there are two major Java versions released every year! We don’t have to wait 3 years or so for new features anymore. Isn’t that cool? 😉

Java was supposed “to be slow”. However, Java turns out to evolve so fast, that next releases aren’t just version bumps, but might significantly change the rules of the game. That’s a good reason to check out what’s new in Java.

To name a few changes:

Some people complain that they’re not doing integration tests “because they take too much time.” All right, the interaction with real dependencies sometimes can’t be made shorter, but there are surely ways to start the databases, message brokers, and so on faster if you happen to use Testcontainers for that.

In this entry, I’ll be using Java. However, since Testcontainers is (from a certain angle) a convenient way to interoperate with Docker-compatible containers using the programming language you know, this should apply to other technology stacks as well. I’m pretty sure that after grasping the idea, one should be able to translate it to Go or C#.

The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies.

Pyramids of testing were also built some time ago. We admire legacy projects with a rich set of tests, but do we create projects today the same way we did 10-15-20 years ago? If not, why do we still want to test them the same way?

During my trainings and lectures, I get asked “but how do you switch Java so fast?” or even “it’s possible to have several versions of Java on your computer at the same time?!” Sure it is!

The way is very simple: use SDKMAN! I use it almost every day, it comes in handy not only during lectures about the latest versions of Java, but in ordinary daily work when you need to check “how it works on another version”.

During my trainings and lectures, I get asked “but how do you switch Java so fast?” or even “it’s possible to have several versions of Java on your computer at the same time?!” Sure it is!

The way is very simple: use SDKMAN! I use it almost every day, it comes in handy not only during lectures about the latest versions of Java, but in ordinary daily work when you need to check “how it works on another version”.

In the previous post we were testing if Java’s Virtual Threads aren’t used in a way that makes them pinned. It’s because we want our Platform Threads (especially those in the ForkJoin Pool Co.) to keep carrying more and more new Virtual Threads, instead of keeping the engine running while VTs are pinned. (At least as long as we can’t provide our own thread pools to carry VTs.)
Spoiler alert: we’re going to use Testcontainers and Toxiproxy today!

How to enable Virtual Threads?

During my talks about Java 19 (which have the mandatory part dedicated to Virtual Threads), I’ve been asked: how do I enable Virtual Threads in the JVM? quite a few times.

This question carries an assumption that there’s some kind of switch, which has to be activated or hit to “magically” turn good ol’ Threads into Virtual Threads. AFAICT there is no such thing right now, and I rather doubt there will be one in the future. There is no system property, environment variable or java parameter I know of, that would make Virtual Threads be used instead of Platform Threads. (Sure, to be able to use VTs we need to java --enable-preview, but that applies to all preview features, it’s not VTs specific.)