The One Billion Row Challenge (1BRC) started as a way to kill time during the 2023/2024 holidays, asking a simple question: How fast can Java crunch temperature values from a text file and calculate the min, mean, and max per weather station? The catch is that the file has one billion rows, totaling at about 13.8 GB.

The top result came from Thomas Wuerthinger, Quan Anh Mai, and Alfonso Peterssen in 1.5 seconds on 8 cores. That was insanely and unexpectedly fast. But when you take a closer look at the code, you will see that it is beyond your daily dose of Java. It is complex, single-use-case oriented, skips safety features, and most of the tunings applied cannot be easily reused.

This article will show you how to get 80% of the result with simpler and more maintainable code. It will also focus on a single-threaded approach to keep us focused. You can use most of the ideas in your own code easily if you need such tuning. But yes, we will also make decisions that a clean code coach would consider big no-nos.

A version of this presentation can be found at JavaPro and also in the 4/2026 edition.

While running final tests, we noticed extremely erratic runtime behavior. This was difficult to reproduce, but very frustrating because it meant the application runtime increased from 5 to almost 14 minutes. This article describes how we diagnosed the issue and distilled it down to a few test cases. These might help us find some answers. Perhaps we’ve discovered a defect or at least a strange edge case in the JVM.

When our Java code processes certain data first, it compiles machine code that contains many uncommon trap markers, which seem to affect runtime behavior (this is just an observation, not a firm conclusion). When different data is processed later, the JIT compiler sticks with its initial compilation, and the runtime suffers by a factor of 2 to 5. If we change the order of the data, the runtime behavior improves dramatically, and even the data that previously led to the potentially poor code now runs fine.

We can change the code to mitigate the problem, but we are still interested in understanding why Java’s JIT compiler reaches its conclusions and persists with them. The code in question is compatible with almost any Java version and doesn’t use any advanced features.

Since I just read again the advice to always use StringBuilder instead of String concatenation, we will close this chapter once and for all, right now!

Long story short, using StringBuilder instead of String concatenation is just an old myth. In most cases, it is not true anymore. You can safely do a String1 + String2 in your code, and you won’t notice any difference. There are only a few special cases where a StringBuilder is a must.

Logitech’s universal USB receiver supports Linux but when the pairing to the device is lost, one cannot easily repair that without Windows or Mac. The project Solaar fixes that. Follow the steps to bring your mouse or keyboard back to live on Linux. It fixed my Logitech M650 L issue. Thanks!

Recently I saw some benchmarks^[1] about converting int to String and of course, I got curious. This post shows that the results are legit, but have to be taken with a grain of salt.

While the benchmarking started out quite normally, it turned into an investigation of accuracy and meaning. What goes into the result, does the difference make sense, and where does all that noise come from? How much should we care?

At the end, you have learned that time is relative, memory expensive, and a small difference not really worth the effort. Or in English: Don’t believe any random benchmark you just found on the Internet!

Recently, I read posts about some Java loop benchmarks. I am not entirely sure, if the outcome and advise given is correct, so here is my version. I don’t want to blame any of the other tests for being incorrect, but judge for yourself.

Spoiler alert: The type of loop might or might not make a difference and overall, it is rather not the loop that makes the difference but all the other code that leads to conditions that might make some loops run faster, despite the same work/task. And yes, parallelStream() is mostly a bad idea.

This article also will give you a brief glimpse into benchmarking as well as teach you, that most benchmarks are wrong or better, the benchmark is right but the conclusions are wrong. Bring some time, the article got longer than expected. The article is not going to teach you how to benchmark with JMH, how the JVM works, or how that all is executed by the CPU. It might just overwhelm you with facts. But hey, it is not supposed to be the last article on that subject.

When people talk about test cases, they often divide them into positive and negative test cases. This article will make the case for abandoning these terms entirely, especially negative test cases. Why is that term wrong after all? Why do people, who use that term often, come up with horrible test cases? Why don’t we gain anything when people think about negative test case in the sense of the most popular definitions?

This article discusses all of that and gives you material for your next terminology battle with your fellow co-workers. It will also, hopefully, motivate you to approach the search for test case differently. And, last but not least, it is all highly subjective and my personal opinion.

JBake 2.7 addresses an issue with UTF-8 in its property file where you could not get that content into the site without an encoding problem.

The following article will demonstrate all content that can be created by using AsciiDoc and JBake. We can even put AsciiDoc in the header of an article. For more demo stuff, look under the tag demo.

That works for a paragraph too. Up to the first headline.

This is also a test post for styling everything nicely and correctly. If you cannot see it here, it is likely that there has not been a style applied yet.