When migrating database schemas, you rarely get clean, predictable data. Legacy databases often have cryptic column names, partially backfilled fields, nullable values, or columns that are completely empty. That’s why you write custom Java JDBC mappers in the first place: to explicitly control how legacy database columns map to your target Java objects, rather than relying on automatic mapping that may not handle these inconsistencies correctly. But there’s a catch: standard unit tests can pass even when you completely forget to map a field. Because null == null, a missing mapping line looks identical to a column that is legitimately empty in your database.

The intersect command can be used on lists and tables to find the same elements that are in the input list or table and a provided list or table. The input is passed to the command and the other list or table is an argument for the intersect command.

There is no shortage of discussion about AI, and LLMs in particular. This is my personal take on the debate: the claims I question, the concerns I share, and the questions I am still working through. Wild claims abound, from “Soon, we won’t need developers anymore” and “AI is taking over the world” to “LLMs are a dead end,” “LLMs are bad for the environment,” “LLMs commit plagiarism,” and “LLMs are unethical.” And the list goes on.

The following blog post by Karl Tryggvason shows a simple script to get data from a JSON Web Token (JWT) using jq. It is basically splitting the token on the . and then convert each part from base64 encoding. As extra functionality the timestamp fields exp and iat are converted to human readable dates.

Maven uses the Surefire plugin to run unit tests and the Failsafe plugin to run integration tests. The default behaviour of Maven is to run all tests and show a summary at the end. The summary shows how many tests have run and how many failures, errors and skipped tests happened. So every time when you run mvn test or mvn verify all tests will be executed, even when tests are failing. You can speed up your build by stop running tests once a test fails. You must use the Java system properties surefire.skipAfterFailureCount and failsafe.skipAfterFailureCount to make sure Maven will skip running any tests after a test failure has occurred. You can specify a number with the parameter to set how many tests should fail before other tests are skipped. It is possible use these parameters in the plugin configuration in your pom.xml as well.

In my previous post, The Azure Scale Controller is Wilding: Build Your Own Java Fan-Out Orchestrator, we explored how Azure’s default queue autoscaling can easily overwhelm downstream services during large fan-out operations.

While managing concurrency solves rate-limiting issues, another silent budget-killer remains: unresponsive, frozen code.

A while ago I was stuck on a problem. I had been turning it over on my own for the better part of a morning, and I was not getting anywhere.

Then I walked to the coffee machine. A colleague asked what I was working on, I explained it in two sentences, and before my cup was even full he said something that pointed me straight at the answer. No meeting, no ticket, no scheduled call. Just two people standing next to a machine that makes mediocre coffee, tea for me.

That is the kind of moment I have been missing, and I think a lot of teams are missing it too.

Discover how to build your own, offline "LocalStack" for Google APIs using WireMock and TestContainers. In this post, I will show you how to set up a two-purpose mocking strategy. By writing your JSON mock responses just once, you can reuse them to power automated integration tests and spin up a standalone mock server for local (UI) development. No more production data and sharing of google keys between developers, no more 403 User Rate Limit Exceeded.

While working on a Spring Boot 4 service using Java 25, I wanted to protect my external API calls as these can go down every now and then. For this I used Resilience4j @CircuitBreaker and @Retry annotations, and put a @Cacheable on top. Three annotations stacked on a single method, what could possibly go wrong?

It turns out that the order in which they are applied by default is probably not the one you want. This makes your circuit breaker count every retry attempt as a separate failure. And once the circuit opens it even blocks data that is sitting right there in your cache. Here is what happens by default, and how I changed it.

As a consultant I am part of a lot of different Java projects. Some of these project use Lombok. When you use a Lombok annotation code gets generated when the code is compiled. This code is not visible in the IntelliJ IDEA editor which could be a problem when you want to debug your application and need to add a breakpoint for the generated code. Suppose you have a Java class with a simple constructor without using Lombok annotations. You can place a breakpoint in the constructor and when you debug the application in IntelliJ IDEA the execution stops at the breakpoint. Now you can check for example the values of parameters that are passed into the constructor call. But when you use a Lombok annotation like @RequiredArgsConstructor the code for the constructor is generated and not visible in your editor. If you want to check the values of parameters passed into the constructor you need to set a breakpoint at the line that has the @RequiredArgsConstructor statement. When you debug your application IntelliJ IDEA will stop execution when the constructor is invoked and you can check values of parameters.