When we apply the Java plugin to our Gradle project we can configure which Java version we want to use for compiling our source code and running our tests using a toolchain configuration. The benefit of having a toolchain configuration is that we can use a different Java version for compiling and running our code than the Java version that is used by Gradle to execute the build. Gradle will look for that Java version on our local computer or download the correct version if it is not available. To search for a local Java installation Gradle will look for operating system specific locations, installations by package managers like SKDMAN! and Jabba, IntelliJ IDEA installations and Maven Toolchain specifications. Maven Toolchain specifications is an XML file describing the location of local Java installation. Each Java installation is described by a version and optional vendor it provides and the location of the installation. Maven uses this information to find the correct Java installation when the maven-toolchain-plugin is used in a Maven project. But Gradle can also utilize Maven Toolchain specifications to find local Java installations. This can be useful when we have to work on multiple projects where some use Maven and others use Gradle. We can place the Maven Toolchain specification file in our Maven home directory. This is also the default place where Gradle will look, but we can use a project property to override this location.

Spring Boot 3 requires at least Java 17, but that also means the Java version used by Gradle must also be at least 17. Otherwise we will get the following error message when we build our Spring Boot project in IntelliJ using Gradle:

The issue is that the Spring Boot Gradle plugin 3.1.5 requires Java 17, but our project is using Java 11. We can fix this by explicitly setting the Java version that Gradle uses in IntelliJ. Go to Settings > Build, Execution, Deployment > Build Tools > Gradle and change the JVM used for Gradle to a JDK version of at least version 17.

Since this month, anyone using the OWASP dependency check plugin from Jeremy Long(*1) needs to upgrade to version 9. The older versions are no longer supported and could fail to work.

It is also recommended to get an NVD api key(*2), else the NVD update can take a very long time. The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP) (*3). Since most of us are using a build environment, we don’t want to create a key for every project, but if we do not, we might get rate-limit errors.

Sometimes we want to send HTTP requests to servers that use HTTPS with self-signed certificates. We then need to tell HTTP Client to not check the certificate of the server. This is like running the curl command with the --insecure or '-k' flag. To disable the certificate verification for HTTP Client we need to adjust the http-client.private.env.json file. For the environment we want to disable the certificate verification we must add a SSLConfiguration section. In the SSLConfiguration section we add the verifyHostCertificate property with value 'true'.

Dear Diary,

"Hobbits really are amazing creatures. You can learn all that there is to know about their ways in a month, and yet after a hundred years they can still surprise you"^[1]. The astonishment Gandalf experiences, that you know something very well but somehow overlooked it, is not unfamiliar to me. Well, let me tell you a story…​

Dear Emily,

You know that feeling when it suddenly clicks? Something you never knew or could not understand. And then, boom, this new knowledge is there for the taking. Well, I had this experience some time ago.

I’m maintaining an application, which is using the Keycloak Spring Security adapter. Now that Keycloak deprecated their adapter, without providing a migration guide, I had to find a solution.

When we use the IntelliJ HTTP Client we can write Javascript for the pre-request and response handlers. The Javascript code must be in between {% …​ %} delimeters. If we want to re-use Javascript functions in the pre-request or response handlers we can store them in an external Javascript file. Then we use the import statement to import either the whole file or specify explicitly the code we want to import. This way we can reuse code for different pre-request and response handlers.

The built-in IntelliJ HTTP Client is very useful for testing HTTP requests and responses. We can use it to test for example a REST API that works with JSON data. If an endpoint expects a JSON payload we can specify the payload in our HTTP Client request file. But if we have a lot of endpoints and large payload the request file can get big and messy. Instead of having the payload in the request file directly we can specify an external JSON file with the payload and use it for a request body. We must use the < operator and give the name of the file with our JSON payload. The IntelliJ HTTP Client will read the contents of that file and use it as the request body. The payload may also contain (dynamic) variables and those variables will be replaced with correct values when the request is executed.

When we think of greatness in the world of sports, one name that immediately pops in my mind is Michael Jordan. Widely regarded as the greatest basketball player of all time, Jordan’s approach to his craft is legendary. While the world of software engineering might seem miles apart from the basketball court, there are valuable lessons we as software engineers can learn from the Michael Jordan approach and apply them to our work as software engineers.