JDriven Blog

Overloading the Primary Constructor in Kotlin for Java Interoperability

Posted on by  
Riccardo Lippolis

One of the great features of Kotlin is its interoperability with Java code. This allows you to easily call 'traditional' Java code from your Kotlin code, but it also helps you the other way around: calling Kotlin code from Java.

Sometimes, a little extra work is needed to make some shiny Kotlin feature work with Java code. For example, Kotlin supports default parameter values, which are not supported in Java. In this case, the @JvmOverloads annotation can be used to generate overloads for functions that contain parameters with default values. This annotation does not only work on functions, but can also be applied on constructors. In this post I will explain how to use this feature on the primary constructor, as it might be confusing where to place the annotation.

Continue reading →

Automatically migrate WebSecurityConfigurerAdapter

Posted on by  
Tim te Beek

If you’ve been working with Spring Security for a while, it should come as no surprise that from time to time, they deprecate the old, and guide you towards the new. In 5.7.x such a change involves the often used WebSecurityConfigurerAdapter.

In Spring Security 5.7.0-M2 we deprecated the WebSecurityConfigurerAdapter, as we encourage users to move towards a component-based security configuration.

And while there are blog posts, release notes, and even an instruction video to highlight the required changes, in the end you will have to change your code. But what all those sources so far have failed to cover, is that there’s now also an easier way to migrate your code, using OpenRewrite.

Continue reading →

Groovy Goodness: Using Macros For Getting More Information About Variables

Posted on by  
Hubert Klein Ikkink

In a previous post we learned about the macros SV, SVI and SVD that return a string representation of variables with their name and value. Groovy 4 also added the NP and NPL macros that we can use to inspect variables. Instead of returning a GString instance these macros return a NamedValue instance or a list of NamedValue value instances. The NamedValue class is a simple class with a property name, containing the name of the variable, and property val with the value of the variable. The macro NP can be used when we have a single variable and result is a single NamedValue instance. An the macro NVL can be used with multiple variables. The result is a list of NamedValue instances where each instance represent a variable passed as argument to NVL.

Continue reading →

Groovy Goodness: Using Macros For Getting String Representation Of Variables

Posted on by  
Hubert Klein Ikkink

Groovy 4 added some built-in macros that we can use in our code. A macro is code that will create new code. It does this by manipulating the Abstract Syntax Tree (AST) before the code is compiled. So when we use a macro, the macro will change the AST and those changes will be compiled. The three built-in macros SV, SVI and SVD can create a GString instance with the names and values of the variables that are passed as argument. This can be very useful to create some meaningful debugging statements. Normally we would have to type in the variable name ourselves followed by the value. Now with these macros we don’t have to type the variable as the macro will add that to the AST for us.

Continue reading →

DataWeave Delight: Using Literal Types

Posted on by  
Hubert Klein Ikkink

DataWeave has a nice language feature called literal types. Literal types are types with a single predefined values and can be defined using a String, Number or Boolean value. So the value of a literal type is a fixed value. We can combine multiple literal types into a new type using a union type to define an enumaration in DataWeave. The enumaration can only be one of the literal types used to define it.
Together with overloaded functions literal types are very useful. We can define a function where one of the input arguments is a literal type to define specific behaviour based on the literal type. Then we can overload the function for other literal types with different behaviour. DataWeave will make sure the correct function is called based on the value of the input argument and how it matches to the literal type value.

Continue reading →

shadow-left