When bytes
meet Mike

Back in 2023, I got extremely excited about the release of Java 21. It felt like a significant breakthrough, similar to Java 8. I was also one of the early adopters of virtual threads in my production code. Back then, thread pinning was the main limitation of this promising solution. The negative impact of thread pinning was initially exaggerated. Shortly after the Java 21 release, many popular frameworks and libraries were updated to become more virtual-threads-friendly. For many standard web apps, updating dependencies was enough to enjoy great scalability and simplicity that virtual threads bring. Yet, I still found it reasonable to keep an eye on thread pinning using Java Flight Recorder (JFR), as I suggested in one of my articles.

2024 was eventful, but professionally quiet. I didn’t speak at major tech conferences, write as many blog posts, or spend as much time on technical deep dives. Still, it was one of the most important years in my almost 12-year career. It was just a bit different. 2024 was a year of scaling myself. Instead of working more, I’ve been exploring ways of making an impact differently. I encouraged people to act, sponsored others’ ideas, and even tried a bit of coaching. Working this way was rather new to me. While I’ve been learning from my mistakes, I’m pretty satisfied with the results.

In my previous article about Java Virtual Threads I focused on different pinning cases caused by the synchronized construct. Some of the presented cases were far from being evident just by looking at the code. That’s why I believe that actively monitoring our apps for pinning is a must. We don’t know if the pinning happens in our app if we’re not monitoring it. We don’t know how frequently it occurs. We don’t know for how long our treads are pinned. Without monitoring, we can only speculate about how pinning affects our application’s performance. I prefer measuring than guessing.

If you heard about Java Virtual Threads, you also heard about the pinning phenomenon. Yet, many articles I found online stop at “replace synchronized with ReentrantLock and don’t use native methods or foreign functions”. While I don’t want to discuss the second part here, I think good-old synchronized deserves a bit more attention. Note: If you are not familiar with Virtual Threads pinning, I suggest starting with the official Virtual Threads documentation.

Orchestration code organizes calls to other components (dependencies) into a certain process. Such pieces of code are sometimes called coordinators or controllers. Orchestration code is usually simple. There’s no (or almost no) conditional logic, or algorithmic complexity. Its main job is to delegate the work to appropriate dependencies in a specific order. Separating orchestration from the actual “heavy” work is a good thing. This way they can be tested independently. Theresulting code units are smaller and thus more testable. Yet, orchestration code itself rarely benefits from unit testing.

Everybody knows that programmers are spoiled. When not enjoying free fruits in their fancy offices, they probably work from the end of the world that looks like a paradise. Even during challenging economic conditions, the market still tries to exceed their expectations… A comfortable life and great earnings - who wouldn’t want that? In fact, there’s much more to appreciate. Most developers experience levels of organizational maturity that other industries have never dreamed of. The work culture that has developed over the years really stands out. Yet, we programmers rarely notice that.

Equals ignoring fields is a pretty common operation. While often used within the test code to exclude selected fields from equality assertions, it can also be handy in our domain code. With Kotlin data classes, we can implement equals ignoring fields without using reflection or extra libraries. This solution feels almost too simple to describe, but it’s interesting to compare it with the available alternatives. Status quo Let’s take a simple blog post representation as an example:

Not all Java releases receive the same attention from the community. The ones marked as “LTS” have a much higher chance of broad adoption (even if many of us don’t fully understand what the “LTS” means). This alone makes the recently released Java 21 a serious contender. I believe it’s the most influential Java release since Java 8. Just not all of its groundbreaking aspects are already evident to everybody… Let me explain what makes this release so promising.

Imagine we’re building yet another e-commerce platform. One of its crucial business processes is, of course, processing an order. After a successful payment, the Orders module (domain) has to call Warehouse asynchronously to prepare purchased goods. Yet, they may not be there. Usually, it’s not a big deal, since we can get them from our suppliers. But what if any of the items are not available anymore? The order has been already placed! Money has changed hands. Our customer is already waiting for delivery. We have no choice - the order has to be canceled.

I launched my own brand “Mike my bytes” in November 2020 as an experiment. Rebooting my existing blog (dated back to 2015!) along with becoming active on Twitter really paid off. Apart from joy, it also brought thousands of people interacting with my content every month. Today, it’s high time to make some adjustments. Refreshed mikemybytes.com design is just the beginning. Content is king The Twitter I discovered in 2020 is no longer there. X feels like a never-ending experiment with a rather uncertain future. Its competition is segmented more than Android versions, without any clear successor (at least in the EU). Yet, some tech people already gave up and moved somewhere else. It’s hard to blame them - the overall experience is much worse now. At least without a paid subscription…