Matter of taste. It is your decision.

But I can explain, why I never use constructor injection.

1. I don't want to implement a constructor for all my @Service, @Repository and @Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.

2. What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 8 parameters is very ugly.

3. If I'm using CDI, constructor does not concern me.

EDIT: Vojtech Ruzicka said:

class has too many dependencies and is probably violating single responsibility principle and should be refactored

Yes. Theory and reality. Here is en example: DashboardController mapped to single path *:8080/dashboard.

My DashboardController collects a lot of informations from other services to display them in a dashboard / system overview page. I need this single controller. So I have to secure only this one path (basic auth or user role filter).

Matter of taste. It is your decision.

But I can explain, why I never use constructor injection.

1. I don't want to implement a constructor for all my @Service, @Repository and @Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.

2. What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 4+ parameters is very ugly.

3. If I'm using CDI, constructor does not concern me.

EDIT #1: Vojtech Ruzicka said:

class has too many dependencies and is probably violating single responsibility principle and should be refactored

Yes. Theory and reality. Here is en example: DashboardController mapped to single path *:8080/dashboard.

My DashboardController collects a lot of informations from other services to display them in a dashboard / system overview page. I need this single controller. So I have to secure only this one path (basic auth or user role filter).

EDIT #2: Since everyone is focused on the 8 parameters in the constructor... This was a real-world example - an customers legacy code. I've changed that. The same argumentation applies to me for 4+ parameters.

It's all about code injection, not instance construction.

Matter of taste. It is your decision.

But I can explain, why I never use constructor injection.

1. I don't want to implement a constructor for all my @Service, @Repository and @Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.

2. What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 8 parameters is very ugly.

3. If I'm using CDI, constructor does not concern me.

Matter of taste. It is your decision.

But I can explain, why I never use constructor injection.

1. I don't want to implement a constructor for all my @Service, @Repository and @Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.

2. What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 8 parameters is very ugly.

3. If I'm using CDI, constructor does not concern me.

EDIT: Vojtech Ruzicka said:

class has too many dependencies and is probably violating single responsibility principle and should be refactored

Yes. Theory and reality. Here is en example: DashboardController mapped to single path *:8080/dashboard.

My DashboardController collects a lot of informations from other services to display them in a dashboard / system overview page. I need this single controller. So I have to secure only this one path (basic auth or user role filter).