When using dependency injection frameworks like Spring or Micronaut, you will often have services, that depend on services, …. While back in the days, annotating fields with @Inject or @Autowired was acceptable, it felt out of favour, because you would never know what a service really depends on. So nowadays injection is usually done via the constructor.

But this also means, that you will find yourself often fiddling around with constructors and orders of arguments. You also will find yourself falling back to the help of your IDE. But if you have the slightest sense of order, you will also find, that the generated code does not keep your order of things: e.g. IntelliJ always adds new fields to the end of the c'tor - and also the assignment to the field inside the c'tor. So you either delete the whole c'tor and recreate again or you will end up using more IDE features to re-arrange your code.

Given that usually those c'tors are only used by CI automatically and maybe in your tests, can't we do better and just let the compiler generate the c'tor for us -- instead of moving words around with your editors?

Groovy comes with TupleConstructor, which can create a c'tor with explicit arguments (in contrast to MapConstructor, which is used to construct via passed in maps to make it look like Groovy would support named arguments). The defaults of TupleConstructor are very un-strict, though. By default, it creates a c'tor for each additional property where the default is null. Usually not what we want with DI, because it does not know which c'tor to use now or might use the wrong one and we end up in the place, that we wanted to avoid when going with c'tor based injection.

But luckily TupleConstructor can be configured to high degree. These settings will give you a pretty good default:

@groovy.transform.TupleConstructor(
        includeFields = true,  // add fields to the c'tor
        defaults = false // do not generate versions of the c'tor with null assignments
)

So now instead of writing this every time, you can make this a new annotation to easily use (and still be able to override the nuances, if you have to), with AnnotationCollector. E.g.

@groovy.transform.TupleConstructor(
        includeFields = true,  // add fields to the c'tor
        defaults = false // do not generate versions of the c'tor with null assignments
)
@groovy.transform.AnnotationCollector
@interface ServiceConstructor {}

Now you can use this annotation instead:

@Service
@ServiceConstructor(
        excludes = ['message'] // if you have transients, add them here
)
class MyService {

    protected final HelloService helloService

    transient protected String message

    @PostConstruct
    void init() {
        message = helloService.sayHello("World")
    }
}

This will generate the c'tor you expect: MyService(HelloService helloService). And if you need your FormatService too, you just add it as a field -- at the place you like. And the c'tor will honour your order in the code.

One downside though is the loss of making your IDE show the usages of the c'tor -- but then, this is often only useful for tests. In that case you can still use your IDE to generate the c'tor, maybe adjust, find the usages and fix them and then delete the c'tor again. There sadly seems not to be a flag to make TupleConstructor throw, if there are existing c'tors. It will by default just silently not generate a c'tor, which is not the worst.

Since version 2 Vaadin Hilla no longer needs endpoints to be .java files to be parsed. Now the endpoints are determined by analyzing the generated classes. So in theory any JVM language can be used now for endpoints - as long as the result comes close enough to what the Java compiler would produce.

For Groovy this means to annotate the @dev.hilla.Enpoint classes with @groovy.transform.stc.POJO and @groovy.transform.CompileStatic.

@CompileStatic is no stranger, but @POJO is new since Groovy 4.0; both combined will result in byte-code, that is very close to what the Java compiler would produce from a similar .java file. Yet you are still able to use Groovy code and annotations.

Complete example:

package com.example.application.helloworld

import com.vaadin.flow.server.auth.AnonymousAllowed
import dev.hilla.Endpoint
import jakarta.annotation.Nonnull
import jakarta.validation.constraints.NotEmpty

@Endpoint
@AnonymousAllowed
@groovy.transform.stc.POJO      // XXX
@groovy.transform.CompileStatic // XXX
class HelloWorldEndpoint {

    private final HelloWorldService helloWorldService

    HelloWorldEndpoint(HelloWorldService helloWorldService) {
        this.helloWorldService = helloWorldService
    }

    @Nonnull
    String sayHello(@NotEmpty String name) {
        return helloWorldService.sayHello(name)
    }
}

When using the Gradle Versions Plugin I sometimes want to cap/restrict versions because things do not line up properly.

E.g. with a (currently) stable Vaadin v23 project I want to stick with Springboot 2.7 (not 3.0, as this brings all the jakarta shenanigans). So you can use rejectVersionIf and look into the designated versions.

tasks.named('dependencyUpdates').configure {
    rejectVersionIf {
        // stick with Springboot 2.X until Vaadin also switches to Jakarta-packages
        it.candidate.group=="org.springframework.boot" && !it.candidate.version.startsWith("2.")
    }
}

Sadly we don't have better means to check the versions. Doing versions via strings feels a little bit like banging stones together to make fire.

When writing more involved Babashka scripts, we usually want to extract some common functionality out into library files. Yet there seems to be no established default, where Babashka is looking for those. So if you want to require a lib-namespace, you can set it up like this:

• Create a lib.bb (or lib.clj) file; if both exist, the .bb one is used; add (ns lib) to the top.
• Add . to the class-path.

The later can be done via:

• Run Babashka with the -cp parameter:

bb -cp . run.bb

• Create a bb.edn file and set :paths:

{:paths ["."]}

Slightly more involved ways can be found in the project setup section of the Babashka docs