helidon-main

# helidon-inject <b>Helidon Injection</b> is an optional feature in Helidon. At its core it provides these main features: 1. A service registry. The service registry holds service providers and are (or otherwise can produce) services. Each service provider in the registry advertises its meta-information for what each service provides, and what it requires in the way of dependencies. 2. A lifecycle engine. Each service provider in the registry remains dormant until there is a "demand for activation". This "demand for activation" is also known as "lazy activation" that can come in different ways. One way is to simply "get" a service (or services) from the registry that matches the meta-information criteria you provide programmatically. If the service (or services) need other services as part of the activation then those services are chain activated, recursively. Helidon Injection provides graceful startup and shutdown at a micro service-level as well as at a macro application level for all services in the service registry. 3. Integrations and Extensibility. More will be mentioned on this later. Over the foundation of these three main features of "services registry", "lifecycle", and "extensibility" there are a number of other tooling and layers that are delivered from various Injection submodules that provide the following additional features and benefits: 1. A minimalist, compile-time generated dependency injection framework that is free from reflection, and compliant to the JSR-330 injection specification. Compile-time source code generation has a number of advantages, including: (a) pre-runtime validation of the DI model, (b) visibility into your application by providing "less magic", which in turn fosters understandability and debug-ability of your application, (c) deterministic behavior (instead of depending on reflection and classpath ordering, etc.) and (c) performance, since binding the model at compile-time is more efficient than computing it at runtime. Helidon Injection (through its tooling) provides you with a mix of declarative and programmatic ways to build your application. It doesn't have to be just one or the other like other popular frameworks in use today require. Inspiration for Helidon Injection, however, did come from many libraries and frameworks that came before it (e.g., Jakarta Hk2, Google Guice, Spring, CDI, and even OSGi). Foundationally, Injection provides a way to develop declarative code using standard (i.e., javax/jakarta, not Helidon specific) annotation types. 2. Integrations. Blending services from different providers (e.g., Helidon services like WebServer, your application service, 3rd party service, etc.) becomes natural in the Injection framework, and enables you to build fully-integrated, feature-rich applications more easily. 3. Extensibility. At the micro level developers can provide their own templates for things like code generation, or even provide an entirely different implementation from this reference implementation Helidon provides. At a macro level (and post the initial release), Injection will be providing a foundation to extend your Guice, Spring, Hk2, CDI, <fill-in the blank> application naturally into one application runtime. The Helidon team fields a number of support questions that involve this area involving "battling DI frameworks" like CDI w/ Hk2. In time, Helidon Injection aims to smooth out this area through the integrations and extensibility features that it will be providing. 4. Interception. Annotations are provided, that in conjunction with Helidon Injection's code-generation annotation processors, allow services in the service registry to support interception and decoration patterns - without the use of reflection at runtime, which is conducive to native image. The Helidon Team believes that the above features help developers achieve the following goals: * More IoC options. With Helidon Injection... developers can choose to use an imperative coding style or a declarative IoC style previously only available with CDI using Helidon MP. At the initial release (Helidon 4.0), however, Injection will only be available with Helidon Nima support. * Compile-time benefits. With Injection... developers can decide to use compile-time code generation into their build process, thereby statically and deterministically wiring their injection model while still enjoying the benefits of a declarative approach for writing their application. Added to this, all code-generated artifacts are in source form instead of bytecode thereby making your application more readable, understandable, consistent, and debuggable. Furthermore, DI model inconsistencies can be found during compile-time instead of at runtime. * Improved performance. Pushing more into compile-time helps reduce what otherwise would need to occur (often times via reflection) to built/compile-time processing. Native code is generated that is further optimized by the compiler. Additionally, with lazy activation of services, only what is needed is activated. Anything not used may be in the classpath is available, but unless and until there is demand for those services they remain dormant. You control the lifecycle in your application code. * Additional lifecycle options. Injection can handle micro, service-level activations for your services, as well as offer controlled shutdown if desired. Many DI frameworks start simple and over time become bloated with "bells and whistle" type features - the majority of which most developers don't need and will never use; especially in today's world of microservices where the application scope is the JVM process itself. *** The <b>Helidon Injection Framework</b> is a reset back to basics, and perfect for such use cases requiring minimalism but yet still be extensible. This is why Injection intentionally chose to implement the earlier JSR-330 specification at its foundation. <i>Application Scope</i> == <i>Singleton Scope</i> in a microservices world. *** Request and Session scopes are simply not made available in Helidon Injection. We believe that scoping is a recipe for undo complexity, confusion, and bugs for the many developers today. ## Terminology * DI - Dependency Injection. * Inject - The assignment of a <i>service</i> instance to a field or method setter that has been annotated with <i>@Inject</i> - also referred to as an injection point. In Spring this would be referred to as 'Autowired'. * Injection Plan - The act of determining how your application will resolve each <i>injection point</i>. In Injection this can optionally be performed at compile-time. But even when the injection plan is deferred to runtime it is resolved without using reflection, and is therefore conducive to native image restrictions and enhanced performance. * Service (aka Bean) - In Spring this would be referred to as a <i>bean</i> with a <i>@Service</i> annotation; These are concrete class types in your application that represents some sort of business logic. * Scope - This refers to the cardinality of a <i>service</i> instance in your application. * Singleton - jakarta.inject.Singleton or javax.inject.Singleton - This is the default scope for services in Helidon Injection just like it is in Spring. * Provided - jakarta.inject.Provider or javax.inject.Provider - If the <i>scope</i> of a <i>service</i> is not <i>Singleton</i> then it is considered to be a Provided scope - and the cardinality will be ascribed to the implementation of the Provider to determine its cardinality. The provider can optionally use the <i>injection point</i> context to determine the appropriate instance and/or cardinality it provides. * Contract - These are how a service can alias itself for injection. Contracts are typically the interface or abstract base class definitions of a <i>service</i> implementation. <i>Injection points</i> must be based upon either using a contract or service that Injection is aware of, usually through annotation processi