Hibernate is a great Object Relational Mapping (ORM) library for accessing data in a relational database. It is one of the leading implementations of Java Persistence (formerly known as JPA). Using JPQL (based on HQL, which is still a nice syntax guide) one can access and update the data in the database through your ORM objects in a simplified SQL way. However, when implemented incorrectly one can run into serious performance problems. They can all be avoided though. Here are some important things to consider to make your queries performant.

When developing software I find it very useful to stick to a number of rules. They are all commonly known, but it can be very convenient to have list of them. Sticking to these rules will enhance the quality of your code drastically.

We all know mocking libraries like Mockito or Mockk to mock classes in our unit tests. They can be convenient to mock I/O with external systems by replacing the boundary classes (aka. DAO = Data Access Objects) with mock objects. That way we do not require a full-blown simulator of that external system. However, mocking using these libraries also has some drawbacks. One way to avoid these drawbacks is to write your own mocks.

Suppose you are testing a set of Quarkus based microservices. They run as Docker images inside a Kubernetes cluster on your local machine, e.g. using MiniKube or Rancher Desktop. At some point you find a bug in one of the services, or you find that you need an extra logging in code. Now you would like to quickly modify the code and redeploy it in your Kubernetes cluster. Typically your Docker image is build using a build pipeline on a build server, which may take several minutes. Can this be done any faster and easier? With Skaffold you can!

When using mutual TLS (mTLS), the client authenticates the server by checking whether the server’s certificate is signed with a trusted CA certificate, i.e. a certificate that exists in its trust store. And vice versa, the server authenticates the client by checking the client’s certificate against its truststore. Both authentications are done at TLS level. Mutual TLS thus requires truststores and keystores on both the client and server side. One-way TLS only requires a keystore on the server side, and a truststore on the client side. So one-way TLS requires a simpler client setup, because it does not need a client specific keystore. But how does authentication work with own-way TLS. Specifically, how does one protect againts a man-in-the-middle attack?

The Gradle Java plugin extends the Base plugin and provides the tasks needed to build a Java (or Kotlin) project. They resemble the Maven build phases for those familiar with Maven. See also Migrating Builds From Apache Maven - Understanding the build lifecycle However, the output from Gradle generally is very different than that of Maven, usually more concise. This is not always what you want. Below you will find some nice commands, options, and configurations that can make the output to the console more complete (a bit more like Maven). This can be particularly helpful when building in a pipeline (eg. GitLab, GitHub, etc.), in which case log files and build reports are usually less or not available. Most of the time all you have is the output to standard out, in which case you would like it to be as complete as possible, specially when the build fails.

If you are familiar with the layers architectural pattern, it is only a small step to the even nicer hexagonal pattern. Here is an example of how you can do it.