When bytes
meet Mike

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.

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.

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…

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!

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.

The calendar doesn’t lie. A decade of my professional career in software development has just passed. 10 years of experience always felt like a magical and very distant boundary. Am I a better engineer now? Am I a different person? Absolutely! Yet, it didn’t happen overnight. Reviewing these changes is a fascinating exercise. Sometimes I struggle to remember what I had for lunch the day before… But 10 years?! That’s really a lot of time!

Quite some time ago, JUnit’s @CsvAnnotation caught my attention. It turned out so interesting, that I dedicated it a separate blog post and a significant part of a conference talk. It also inspired me to create a new way of writing parameterized tests with JUnit 5. The JUnit 5 FormattedSource library allows defining test case arguments in a human-readable way, following a user-defined format. As a result, it can be used to improve tests readability.