Field injection in quarkus

[BrianH85]

From Sonarqube we have been getting code issues concerning field injection. For example the article here describes it: https://www.baeldung.com/java-spring-field-injection-cons

Are some or all of these concerns also valid when using Quarkus field injection? I'm trying to figure out if and when we should use constructor injection instead.

[quarkus-bot[bot]]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[Pankraz76]

No offense meant—Quarkus and Spring are very similar, even pointing this out on the website itself.

I don’t see any rivalry here, as competition is in everybody’s favor. I’m just an observer in a free world.

[Pankraz76]

Actually just wanted to suggest that quarkus should offer the same feature, assuming its currently not.

[Pankraz76]

• CDI: Preventing (Unbreakable) Circular References #48516

[Pankraz76]

any way

class A {
    @ApplicationScope
    final B b;
    
    A(B b) {
        this.b = b;
    }
}

class B {
    @ApplicationScope
    final A a;
    
    B(A a) {
        this.a = a;
    }
}

public class Main {
    public static void main(String[] args) {
        // Create the circular reference
        A a = new A(null);
        B b = new B(a);
        a.b = b;  // This won't compile because b is final
        
        // The proper way requires either:
        // 1. Breaking the final requirement, or
        // 2. Using a setter method (but then fields can't be final)
    }
}

when using some random AC with field injection this brilliant code is possible, when using constructor it seems a little bit more difficult, close to impossible, at least for my very limited skills.

How does this not make any difference?
@Ladicek

[Ladicek]

What you're doing I assume is simulating manual creation of dependencies, which only makes sense in tests -- and indeed Java as a strictly evaluated language does not allow creating reference cycles of immutable objects. This has nothing to do with constructor/field injection or anything framework-level. This is just how the Java language works.

[Ladicek]

The concerns in the linked article generally apply to all full-featured dependency injection containers, including CDI. From a purist perspective, constructor injection should obviously be preferred to field injection. On the other hand, field injection is immensely pragmatic (what's the point of writing a constructor that just assigns its parameters to fields?). Specifically when it comes to testing and mocking, Quarkus has multiple tools that make testing a breeze even in presence of field injection (see https://quarkus.io/guides/getting-started-testing).

[manovotn]

Ladislav is right on the money.
I'd just add that for some beans in CDI (normal-scoped beans - req. scoped, app. scoped) you will need to provide a no-args constructor in order to be able to create client proxy anyway which makes the argument for constructor injection somewhat weaker.
Furthermore, CDI also allows you to use initializer methods which is yet another way of setting up your fields.

[Ladicek]

Note that what CDI calls initializer methods is elsewhere called setter injection.

[mkouba]

And for a good reason - an initializer method in CDI may accept multiple params, so it's not a classic "setter" ;-).

[edeandrea]

To be honest I always prefer constructor injection over field injection. It makes it explicitly clear what fields are required to instantiate a class and therefore make it useful. You have no idea how many times I've been bitten over the years with mocking and field injection where if a field (that is field injected) is added later on, then the tests break, whereas with constructor injection (& setting the fields as private final) your IDE complains immediately about it, which is a good thing.

Additionally, having fields as package private just feels wrong to me. Fields should be private, and private final is even better.

Just my own $0.02 but I just don't like field injection and always prefer constructor injection.

[Chealer]

For context, sonar-java 7.27.0.33463 added S6813 "Field dependency injection should be avoided". I know nothing about SonarQube, but from my understanding upgrading from SonarQube 9.9 to 10.6 will add that check and therefore cause those using field injection to start getting such warnings. SonarQube 10 seems scheduled to become the "LTA" version this year.

There will likely be numerous Quarkus users wondering how to deal with that soon, since Quarkus's documentation implicitly suggests field injection, as can be seen in this prominent example. Moreover, SonarQube's check has defaultSeverity Major and a impact defined as MEDIUM. Our own projects have roughly a thousand affected fields. One user was already wondering about this on Stack Overflow nearly a year ago.

It would therefore be quite interesting for Quarkus to take an official stance on this matter, and perhaps provide an opinion about how severe this issue truly is in the context of Quarkus. If the impact is lower as @Ladicek suggests, perhaps SonarQube's check could take that into account. And if the impact truly is medium or higher, then surely Quarkus's documentation should not feature such examples without warnings.

Thank you very much for bringing this up @BrianH85 and all others for your contribution

[edeandrea]

HI @Chealer! We're actually in the process of debating this! We're working with the Sonarsource team directly on some proposals.

Feel free to follow/chime in: #43179 (comment)

[Chealer]

I had completely missed that; thank you so much @edeandrea, that's amazing!
@Ladicek , @manovotn: You might want to chime in there.

[mkouba]

I have to admit that I strongly disagree with such warnings - see my comment here: #43179 (reply in thread).

[omasseau]

Sonarqube is still reporting this problem when field injection is used.

In every single page of the Quarkus documentation only field injection is used.

I think that either the Quarkus team should :

• make an official statement in the documentation that field injection is indeed the recommended way to do injection in Quarkus (and inform the Sonarqube devs of this)
• or the documentation should be adapted to use constructor injection if the Quarkus team thinks that constructor injection is still preferred over field injection.
• or say that neither is preferred over the other one and that both ways are legitimate.

Let's not forget that many junior developers learn the best practices through the documentation of the frameworks they use.

[omasseau]

Followup: @see #48480