Improve constructor injection
See original GitHub issueSimiliar to Spring IOC, for a component managed by CDI, if there is only one constructor with parameters, it should be injected automatically without an explicit @Inject
.
private final OrderRepository orders; // OrderRepository is a CDI bean
public class OrderService(OrderRepository orders){ //OrderRepository should be injected automatically here.
this.orders = orders;
}
Similarly the methods of a component should be handled automatically.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:17 (16 by maintainers)
Top Results From Across the Web
Why You Should Use Constructor Injection in Spring
Constructor injection makes code more robust. It allows us to create immutable objects, preventing NullPointerException s and other errors. You ...
Read more >Improve constructor injection · Issue #464 · jakartaee/cdi
Similiar to Spring IOC, for a component managed by CDI, if there is only one constructor with parameters, it should be injected automatically ......
Read more >Best Practices for Dependency Injection with Spring
Constructor based dependency injection is certainly considered a best practice. There was a time I personally favored setter based injection, ...
Read more >How to avoid Dependency Injection constructor madness?
One of the wonderful benefits of Constructor Injection is that it makes violations of the Single Responsibility Principle glaringly obvious. When that happens, ......
Read more >Why is it the recommended approach to Dependency Injection?
In this tutorial, you will learn why Constructor Injection is the recommended approach to dependency injection in Spring.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Actually I realize this is perhaps what you had in mind, so one more clarification.
CDI Lite can’t require build-time implementations to work differently from runtime implementations. Code that works with build-time implementations of CDI Lite must work with runtime implementations of CDI Lite, et vice versa.
Further, CDI Lite can’t even require bytecode manipulation. I’m no expert on Micronaut, but they have very different constraints when it comes to build-time manipulation of existing bytecode than Quarkus.
CDI Lite still requires the bean constructor to be annotated
@Inject
(unless it’s a zero-parameter constructor), and it still requires normal-scoped beans to always have a zero-parameter constructor.Quarkus does 2 things that are outside of the CDI specification:
It is entirely unreasonable to expect that all CDI implementations will want / be able to do what Quarkus does in item 2. Therefore, the CDI specification can’t really “simplify” the lookup of the bean constructor by saying “if there’s only one constructor, then …”, because normal-scoped beans will only have one constructor if it’s the zero-parameter constructor.
My opinion is that explicit is always better than implicit, so I personally don’t really like the “simplification” Quarkus does and I still annotate my bean constructors with
@Inject
.(Fun fact: there’s one special case. If the desired bean constructor is the zero-parameter constructor, it doesn’t have to be annotated
@Inject
. In other words, if there’s multiple constructors and none of them is annotated@Inject
, then the zero-parameter constructor is selected. But that’s been like that since CDI 1.0.)