When adding/removing entities to/from a collection in Hibernate one may easily run into annoying TransientObjectException or TransientPropertyValueException exceptions. This blog uses a simple example to describes how to avoid these issues.

Last weekend I was in London with my daughter for a lovely couple of days and a Bon Jovi concert. We were sitting together in a Costa Coffee when a young couple sat down across us. At first I did not really notice them, only that there were these odd little sounds that kept repeating. Then it clicked, when they stood up and started filming their TikTok dance, the sound turned up loud, with eyes only for the phone that had been carefully positioned for the perfect shot.

A common practice with Hibernate is to give each entity an id field to store its primary key. This field is generally managed by Hibernate. When the entity has not been saved yet, the field is null, which is also how Hibernate detects the object has not been saved yet. Once it is saved, Hibernate sets the value of the id to the generated value. Since the value of the id field changes, it is not suited to base your equals and hashCode methods on. Which is a bit counter-intuitive, because it corresponds to the primary key in the database. The solution is to use Business Keys.

How to represent datetimes in APIs, the code, and the database is always tricky. Most people I have worked with struggled with this. The main mistake is omitting the time zone based on the false assumption that defaults are uniform across systems. They are not. As a result timestamps carried across systems get weird time jumps. This blog gives some rules to avoid these mistakes and gives a clean set up.

After working on Kotlin projects for over seven years, I recently started on a Java project again. One of the things I missed most was the fact that Kotlin explicitly supports nullability as part of its type system. Within the first day I ran into a NullPointerException. Luckily, we can now add compile-time null checks to Java as well, making Java null safe(r)!

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.