https://blog.jdriven.comJDriven Blog2024-03-12T12:00:07.000ZHexohttps://blog.jdriven.com/2024/03/Dear-Diary-Reveal-autoconfigured-Spring-Beans/Dear Diary: Reveal autoconfigured Spring Beans in IntelliJ #Spring2024-03-12T12:00:07.000Z2024-03-12T12:00:07.000Zjacobvlingenhttps://blog.jdriven.com/author/jacobvlingen<div class="paragraph">
<p>Sometimes the answer to your problems is right in front of you.
But somehow you just can’t grasp it until you’ve had a bit of an enlightenment experience.
This happened to me a couple of weeks ago.</p>
</div>https://blog.jdriven.com/2024/03/Gradle-Goodness-Organizing-Tasks-Using-The-Task-Container/Gradle Goodness: Organizing Tasks Using The Task Container #Gradle2024-03-12T05:32:30.000Z2024-03-12T05:32:30.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>A Gradle build file describes what is needed to build our Java project. We apply one or more plugins, configure the plugins, declare dependencies and create and configure tasks. We have a lot of freedom to organize the build file as Gradle doesn’t really care. So to create maintainable Gradle build files we need to organize our build files and follow some conventions. In this post we focus on organizing the tasks and see if we can find a good way to do this.</p>
</div>
<div class="paragraph">
<p>It is good to have a single place where all the tasks are created and configured, instead of having all the logic scattered all over the build file. The <code>TaskContainer</code> is a good place to put all the tasks. To access the <code>TaskContainer</code> we can use the <code>tasks</code> property on the <code>Project</code> object. Within the scope of the <code>tasks</code> block we can create and configure tasks. Now we have a single place where all the tasks are created and configured. This makes it easier to find the tasks in our project as we have a single place to look for the tasks.</p>
</div>https://blog.jdriven.com/2024/03/IntelliJ-HTTP-Client-Parsing-JSON-Web-Tokens/IntelliJ HTTP Client: Parsing JSON Web Tokens #JWT #Testing #REST #IntelliJ HTTP Client2024-03-07T05:29:05.000Z2024-03-07T05:29:05.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>The IntelliJ HTTP Client is very useful for testing APIs. We can use Javascript to look at the response and write tests with assertions about the response. If an API returns a JSON Web Token (JWT), we can use a Javascript function to decode the token and extract information from it. For example we can then assert that fields of the token have the correct value. There is no built-in support in IntelliJ HTTP Client to decode a JWT, but we can write our own Javascript function to do it. We then use the function in our Javascript response handler to decode the token.</p>
</div>https://blog.jdriven.com/2024/02/gpu_part2/GPU programming part 2: architecture details and when to make the switch #GPU #CUDA2024-02-29T07:00:00.000Z2024-02-29T07:00:00.000Zsilvian-bensdorphttps://blog.jdriven.com/author/silvian-bensdorp<div class="paragraph">
<p>Last week we had a quick glance of what GPU programming is and what kind of issues it can tackle.
Today, we will dive a bit under the hood and take a look at the logical architecture of modern chips, and show a basic strategy when to migrate part of our code over to the CUDA platform.</p>
</div>https://blog.jdriven.com/2024/02/Gradle-Goodness-Using-System-Properties-Lazily/Gradle Goodness: Using System Properties Lazily #Java #Gradle #Gradle Goodness2024-02-29T06:36:22.000Z2024-02-29T06:36:22.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>It is good practice in Gradle to use lazy configuration. This makes builds faster as only configuration values are evaluated when needed. We should try to not let Gradle spend time on evaluating configuration values that will not be used. For example tasks that are not executed could still be configured by Gradle. If we make sure the configuration of these tasks is lazy we can save time.</p>
</div>
<div class="paragraph">
<p>Gradle gives us a lazy way to get the value of a Java system property. In our build script we can use the <code>providers</code> property of type <code>ProviderFactory</code> and the method <code>systemProperty(String)</code>. This method returns a <code>Provider<String></code> instance that can be used to get the value of a system property in a lazy way. The method <code>systemProperty</code> can also be used with a <code>Provider<String></code> argument.</p>
</div>https://blog.jdriven.com/2024/02/Gradle-Goodness-Using-Environment-Variables-Lazily/Gradle Goodness: Using Environment Variables Lazily #Java #Gradle #Gradle Goodness2024-02-27T06:34:55.000Z2024-02-27T06:34:55.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>It is good practice in Gradle to use lazy configuration. This makes builds faster as only configuration values are evaluated when needed. We should try to not let Gradle spend time on evaluating configuration values that will not be used. For example tasks that are not executed could still be configured by Gradle. If we make sure the configuration of these tasks is lazy we can save time.</p>
</div>
<div class="paragraph">
<p>Gradle gives us a lazy way to get the value of an environment variable. In our build script we can use the <code>providers</code> property of type <code>ProviderFactory</code> and the method <code>environmentVariable(String)</code>. This method returns a <code>Provider<String></code> instance that can be used to get the value of an environment variable in a lazy way.</p>
</div>https://blog.jdriven.com/2024/02/Kotlin-Discovered-Variance-again/Kotlin Discovered: Variance (again) #Kotlin #TypeDriven2024-02-21T06:58:07.000Z2024-02-21T06:58:07.000Zjacobvlingenhttps://blog.jdriven.com/author/jacobvlingen<div class="paragraph">
<p>You never touched Groovy, nor did you jump on the Scala train.
Clojure never attracted you; and you heard about Ceylon long after the language had already died.
You are one of those old-fashioned Java folks!
But now, after all those years, you want to join the cool Kotlin kids.
So, where to start?
Let’s discover the language together by decompiling it to Java code.
<span class="only-in-preview">Today: The things we tend to forget!</span></p>
</div>https://blog.jdriven.com/2024/02/IntelliJ-HTTP-Client-Accessing-Environment-Variables-In-Javascript/IntelliJ HTTP Client: Accessing Environment Variables In JavaScript #Testing #REST #IntelliJ HTTP Client2024-02-20T06:06:11.000Z2024-02-20T06:06:11.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>When we use the IntelliJ HTTP Client we can write JavaScript for the pre-request and response handlers. If we want to access an environment variable in JavaScript we can use <code>request.environment.get(string)</code>. The argument for the <code>get</code> function is the name of the environment variable we want to get the value for. Environment variables can be defined in the file <code>http-client.env.json</code> or in <code>http-client.private.env.json</code>.</p>
</div>https://blog.jdriven.com/2024/02/IntelliJ-HTTP-Client-Using-In-Place-Variables/IntelliJ HTTP Client: Using In-Place Variables #REST #HTTP Client #IntelliJ IDEA2024-02-15T06:52:39.000Z2024-02-15T06:52:39.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>The built-in IntelliJ HTTP Client is very useful for testing HTTP requests and responses. If we want to define a variable in our <code>.http</code> file that is only used in this file and will not change per environment we can define it using the following syntax: <code>@<variable name> = variable value</code>. The variable is an in-place variable and the scope of the variable in the current <code>.http</code> file. The variable is immutable and can only be defined with a value once and cannot be overwritten. To refer to the variable we use the syntax <code>{{<variable name>}}</code>.</p>
</div>https://blog.jdriven.com/2024/02/GPU-programming-part-1/GPU programming, a high level overview #GPU #CUDA2024-02-14T07:00:00.000Z2024-02-14T07:00:00.000Zsilvian-bensdorphttps://blog.jdriven.com/author/silvian-bensdorp<div class="paragraph">
<p>Over the last year, there has been quite some fuss over using GPU’s for other
tasks than gaming. News stories about AI and cryptocurrency mining requiring
vast amounts of GPU’s; product shortages in the consumer gaming market are just
a few to name. Share prices for semiconductor design companies, particularly
Nvidia, have been soaring. Yet, on the other hand, there is little
understanding in the general software development community as to how these
techniques work, what class of problems they can solve more effectively, and
how and when to use them.</p>
</div>https://blog.jdriven.com/2024/02/Gradle-Goodness-Continuous-Testing-For-Java-Projects/Gradle Goodness: Continuous Testing For Java Projects #Java #Gradle #Testing2024-02-13T06:12:11.000Z2024-02-13T06:12:11.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>The command line option <code>--continuous</code> or the short version <code>-t</code> enables Gradle’s continous build. For a continuous build Gradle will keep on running and will re-execute the tasks we invoked if the input or of the input of one of the depended tasks has changed. For a project with the <code>java</code> plugin we can use this option for the <code>test</code> task. Gradle will run the <code>test</code> task and after the task has been executed Gradle will wait for any changes in the input of the task. This means if we change our Java test code in <code>src/test/java</code> and save the source file Gradle will re-execute the <code>test</code> task and show the output. But also if the input of other tasks changes, that the <code>test</code> task depends on, the <code>test</code> is re-executed. So also changes in source files in our <code>src/main/java</code> directory will trigger a re-execute of the <code>test</code> task, because the <code>test</code> task depends on the <code>compileJava</code> task, and the <code>compileJava</code> task has the <code>src/main/java</code> directory as input.</p>
</div>https://blog.jdriven.com/2024/02/Gradle-Goodness-Java-Toolchain-Configuration-Using-User-Defined-Java-Locations/Gradle Goodness: Java Toolchain Configuration Using User Defined Java Locations #Java #Gradle2024-02-07T07:06:32.000Z2024-02-07T07:06:32.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>With the java plugin we can configure a so-called Java toolchain. The toolchain configuration is used to define which Java version needs to be used to compile and test our code in our project. The location of the Java version can be determined by Gradle automatically. Gradle will look at known locations based on the operating system, package managers, IntellIJ IDEA installations and Maven Toolchain configuration.</p>
</div>
<div class="paragraph">
<p>But we can also define the locations of our Java installations ourselves using the project property <code>org.gradle.java.installations.paths</code>. We provide the paths to the local Java installations as a comma separated list as value for this property. When we set this property we can also disable the Gradle toolchain detection mechanism, so only the Java installations we have defined ourselves are used. To disable the automatic detection we set the property <code>org.gradle.java.installations.auto-detect</code> to <code>false</code>. If we leave the value to the default value <code>true</code>, then the locations we set via <code>org.gradle.java.installations.paths</code> are added to the Java installations already found by Gradle.</p>
</div>
<div class="paragraph">
<p>The property <code>org.gradle.java.installations.paths</code> is a project property we can set via the command line, but we can also set it in the <code>gradle.properties</code> file in our <code>GRADLE_USER_HOME</code> directory. Then the values we define will be used by all Gradle builds on our machine.</p>
</div>https://blog.jdriven.com/2024/02/Gradle-Goodness-Using-Maven-Toolchains-Configuration-For-Gradle-Java-Toolchain-Resolution/Gradle Goodness: Using Maven Toolchains Configuration For Gradle Java Toolchain Resolution #Java #Gradle #Maven2024-02-05T07:06:16.000Z2024-02-05T07:06:16.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>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 <a href="https://docs.gradle.org/current/userguide/toolchains.html">toolchain configuration</a>. 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 <a href="https://sdkman.io">SKDMAN!</a> and <a href="https://github.com/shyiko/jabba">Jabba</a>, IntelliJ IDEA installations and <a href="https://maven.apache.org/guides/mini/guide-using-toolchains.html">Maven Toolchain</a> 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 <code>maven-toolchain-plugin</code> 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.</p>
</div>https://blog.jdriven.com/2024/01/Spring-Sweets-Spring-Boot-3-With-Gradle-In-IntelliJ/Spring Sweets: Spring Boot 3 With Gradle In IntelliJ #Gradle #Spring #Spring Boot #IntelliJ IDEA2024-01-29T09:59:59.000Z2024-01-29T09:59:59.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>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:</p>
</div>
<div class="paragraph">
<p>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 <em>Settings > Build, Execution, Deployment > Build Tools > Gradle</em> and change the JVM used for Gradle to a JDK version of at least version 17.</p>
</div>https://blog.jdriven.com/2024/01/Owasp-DependencyCheck-Plugin-Central-Cache/OWASP DependencyCheck Plugin Central Cache #security #gradle #work #owasp #plugin2024-01-18T15:20:00.000Z2024-01-18T15:20:00.000Zjbrugmanhttps://blog.jdriven.com/author/jbrugman<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>https://blog.jdriven.com/2024/01/IntelliJ-HTTP-Client-Allowing-Insecure-HTTPS-Requests/IntelliJ HTTP Client: Allowing Insecure HTTPS Requests #Testing #REST #IntelliJ HTTP Client2024-01-17T05:50:35.000Z2024-01-17T05:50:35.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>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 <code>--insecure</code> or '-k' flag.
To <a href="https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html#disable_certificate_verification">disable the certificate verification</a> for HTTP Client we need to adjust the <code>http-client.private.env.json</code> file.
For the environment we want to disable the certificate verification we must add a <code>SSLConfiguration</code> section.
In the <code>SSLConfiguration</code> section we add the <code>verifyHostCertificate</code> property with value 'true'.</p>
</div>https://blog.jdriven.com/2024/01/Dear-Diary-Generics-At-Runtime/Dear Diary: Generics at runtime? #Storytelling2024-01-15T05:58:07.000Z2024-01-15T05:58:07.000Zjacobvlingenhttps://blog.jdriven.com/author/jacobvlingen<div class="paragraph">
<p>Dear Diary,</p>
</div>
<div class="paragraph">
<p>"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"<sup class="footnote">[<a id="_footnoteref_1" class="footnote" href="#_footnotedef_1" title="View footnote.">1</a>]</sup>.
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…​</p>
</div>https://blog.jdriven.com/2023/12/Dear-Diary-Operators-are-just-Functions/Dear Diary: Operators are just functions #Storytelling #TypeDriven2023-12-11T05:58:07.000Z2023-12-11T05:58:07.000Zjacobvlingenhttps://blog.jdriven.com/author/jacobvlingen<div class="paragraph">
<p>Dear Emily,</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>https://blog.jdriven.com/2023/12/Migrate-deprecated-Keycloak-adapter-with-Spring-Security-6/Migrate deprecated Keycloak adapter with Spring Security 62023-12-08T13:51:34.000Z2023-12-08T13:51:34.000Ztom-de-vroomenhttps://blog.jdriven.com/author/tom-de-vroomen<div class="paragraph">
<p>I’m maintaining an application, which is using the Keycloak Spring Security adapter.
Now that <a href="https://www.keycloak.org/2023/03/adapter-deprecation-update">Keycloak deprecated their adapter</a>, without providing a migration guide, I had to find a solution.</p>
</div>https://blog.jdriven.com/2023/11/IntelliJ-HTTP-Client-Re-using-Javascript-In-Pre-Request-And-Response-Handlers/IntelliJ HTTP Client: Re-using Javascript In Pre-Request And Response Handlers #IntelliJ #HTTP Client2023-11-09T05:21:46.000Z2023-11-09T05:21:46.000Zmrhakihttps://blog.jdriven.com/author/mrhaki<div class="paragraph">
<p>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 <code>{% … %}</code> 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 <code>import</code> 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.</p>
</div>