My garden is well, how is yours?

Okay, so what does the Software Garden actually mean?

If you’re looking for the original explanation of what the ‘software garden’ is, then I guess you won’t find a better explanation than the one I read years ago in The Pragmatic Programmer by Andrew Hunt and David Thomas.

There are these books, films, paintings, etc. which revolutionise the way you think in certain aspects. Many people took many things from this influential book: some started boiling frogs, some talking to rubber ducks. I was raised close to the nature, therefore in my opinion the software we create and use is much more like a garden than some architecture or machinery. It lives in a way. It’s never done. The whole ecosystem constantly changes. You pray for the rain. The summer comes after the spring. New plants need space. We need to get rid of bugs to have something to eat. You can’t start with green field every week. And so on…

That’s why years ago I changed my headline from ‘Software Developer’ or ‘Software Engineer’ to ‘Software Gardener’. Sure, it confuses and intrigues some people who haven’t read The Pragmatic Programmer. It also allows me to spot a few other folks with the same description of their position, and we instantly recognise each other.

Therefore, this page is meant to be the internet representation of my ongoing journey in Software Gardening. It’s not industry-scale farm with plant monoculture, acres and acres big. It’s my little garden, with seeds I care about, with birds singing in the sky and for sure, with some bugs as well. Consider yourself invited.

Integration tests are needed and simple

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?

SDKMAN! - more

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

SDKMAN! - the beginning

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

Testing (if there are no) pinned Virtual Threads

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 (mis)use Virtual Threads

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

Sailing Modern Java

When I have time to talk about Java for more than one hour, it’s a Deep Dive (I call it “What’s new and noteworthy?”) When I have less than forty minutes, we can barely touch the surface, hence it’s called then “Surfing Modern Java”. Anything in between, like regular-size talk, is more than surfing, but less than deep dive, hence “Sailing Modern Java”.

For such a talk I usually cover one or two latest releases, sometimes mentioning what’s ahead of us, trying to sneak in as many code demos as I can.

Testing Virtual Threads

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.

Java 18 & 19. What's new and noteworthy??

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:

Go Go Java Developer

“You can never understand one language until you understand at least two.” – Geoffrey Willans

For years, I’ve been developing mostly in JVM languages. Sometimes in other C-derived languages, which was both cool and easy.

A few months ago (due to a career shift) I had to learn Go rapidly. While technically Go has keywords looking similar to C, many things are simply different and even unheard of in C-based OOP languages. Learning Go is a great journey and the best are these AH-HA moments, when doing things in Go I suddenly understood Java better.

(mis)using modern Java

Modern Java is really awesome when it comes to “Hello, World!” demos. It’s also cool for a sophisticated systems and algorithms, provided their authors write code which obeys a few fairly simple contracts and avoids obvious traps.

There are a few mantras regarding recent features of modern Java, such as:

  • records can replace JavaBeans everywhere
  • you never need to write hashCode() for records
  • pattern matching with instanceof is the best tool for equals()
  • just ignore --illegal-access and set it to permit
  • synchronize (new Long(42)) is the best for monitoring and so on.

This talk has been given at jLove, Doing Java Better and Java Day Lviv.