InjectMaid
InjectMaid is a lightweight dependency injection framework that does not rely on annotations.
Features:
- Injection via public constructor or static factory method
- Does not call non-public methods nor set non-public fields
- Support for singletons (lazy and eager initialization)
- Generics are fully supported
- Optionally respects
@Injectand@Singletonannotations - Advanced scoping
- Circular dependency detection
- No expensive classpath scanning
Coming soon:
- Pre-compiled reflections
- Support for GraalVM
Limitations:
- No support for field and setter injection
Getting started
The InjectMaid documentation can be found here.
Get in touch
Feel free to join us on Slack or Gitter to ask questions, give feedback or just discuss software architecture with the team behind HttpMaid. Also, don't forget to visit our website and follow us on Twitter!
Frequently asked questions
Can I use InjectMaid without reflection?
Yes. You can easily register all types directly and InjectMaid will not perform a single reflective call.
Is there anything wrong with annotations?
No. But like any other concept, there are downsides. InjectMaid leaves the choice whether to use them to you. You can configure InjectMaid with annotations, but you don't have to.
However, InjectMaid is part of the larger QuantumMaid application framework. QuantumMaid is designed around the concept of clean architecture as defined by Robert C. Martin. Here, developers are encouraged to strictly keep infrastructure code separate from business logic (or domain code in Domain-Driven Design):
This way, infrastructure aspects like databases and public APIs (REST, etc.) are mere replaceable details. Directly annotating business logic with infrastructure annotations like those of JAX-RS, CDI, JSON-B, JSR 303, JPA, etc. removes this strict separation. A common workaround is the creation of wrapper classes whose sole purpose is to carry the infrastructure annotations (controllers, JSON models, etc.). This might be feasible in some cases but introduces a lot of boilerplate overhead.
Another downside to classical annotation processing is its implication on application startup time. A classical JEE container needs to scan all classes in a newly deployed application for annotations to determine its configuration. This is inherently slow and leads to long initialization phases. With the introduction of popular serverless hosting options like AWS Lambda, this becomes a crucial issue. Projects like Google Dagger, Quarkus and Micronaut partially solve that problem by processing annotations at compile time. QuantumMaid offers an alternative approach by avoiding configuration by annotations altogether.
Here are additional (independent) blogs with a similar point of view:
- [https://blog.softwaremill.com/the-case-against-annotations-4b2fb170ed67]()
- [https://medium.com/@vincent.maurin.fr/java-annotations-and-oop-a2633f3692fb]()
Another Java application framework that follows an approach without annotations is the Vlingo Platform. It is actively maintained by Vaughn Vernon, the author of the book Implementing Domain-Driven Design.