Posts

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#.

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.)

Let’s be honest: we’ve been waiting for the Virtual Threads quite some time. We’ve been waiting eagerly, we’ve seen names changing (they’re not fibers folks), but here there finally are: Virtual Threads.

Some say the Project Loom is the biggest change Java has seen since version 8, lambdas, and streams. Some say it’s even bigger than that. Discussion aside, they are a huge change, it seems.

I remember how we were excited (I was still at the university back then), that we could finally use some real Threads in Java on Windows. Yet time flies by, the industry has changed, the hardware has changed, the way we build our systems has changed too. While we found ways to bypass the limitations of “one OS thread per one Java thread”, it came with some price: convoluted stack traces and difficult debugging are the first ones that come to mind. Virtual Threads are about to keep us in the boooring, yet easy to grasp thread-per-request model, while unblocking the silicon power down below.

What do I think about Lombok?

I think it’s a nice island, and I wish to visit it one day.

What do I think about Project Lombok?

Well, I’ve been asked this question so many times, I’ve decided to write this post. Its main purpose is to be able to paste the link and back up, because the (yet another) discussion might be so intensive, that fists will be shaken and heads will roll… There are three assumptions here:

Many features and changes we see coming live in new Java version (if not most of them) are developed under so-called umbrella projects. We frequently see syntax improvements from project Amber, project Jigsaw is about bringing modules, project Loom (surprise, surprise) is about new threads, project Panama roughly speaking is about using native stuff safely and efficiently, and among the most known ones, project Valhalla starts to become a thing, thanks to JEP-390 being included in Java 16.