Dependency Injection

[Remi Forax]

> From: "Red IO" <redio.development at gmail.com>
> To: "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, February 20, 2023 6:59:43 PM
> Subject: Dependency Injection

> Reason/Background:
> I was building a server application (in java) designed around the mediator
> pattern and dependency injection inspired by a c# server application tutorial.
> So I was researching but every dependency injection framework was relying on
> bytecode manipulation to do the injection.

Bytecode manipulation at compile-time (like Quarkus) or runtime (like Spring) ? 
And there are several DI libraries that leverage annotation processors without doing bytecode transformation, i think the most popular is Dagger 2. 

> For background I really dislike bytecode manipulation for production code.
> So I researched what the jdk provides and what not. I discovered that the jdk
> provides service loading capabilities in form of the ServiceLoader api. But it
> is pretty barebones only allowing creation of service implementations providing
> a no-args constructor.

> Idea:
> I thought that this could be expanded to allow loading of services that depend
> on other services (In form of constructor parameters) that can be loaded with
> associated ServiceLoaders.
> So I coded a small test wrapper for ServiceLoader that does the injection of
> known services.
> I used MethodHandles to create factory handles that use the associated loaders
> to fill in the constructor and in that way avoided bytecode manipulation.

I do not understand, once a method handle becomes hot, the JDK will generate the corresponding bytecodes, so how it is different from a DI that generate bytecodes ? 
And usually it's harder to get good performance from method handles if the JIT does not see them as a constant. 

> Suggestion:
> I was wondering if this concept would be interesting to incorporate into the jdk
> as an expansion of the ServiceLoader api.

There was a jlink plugin doing the ServiceLoader resolution at link time if the service was specified in the module-info, i do not know if it still exist or not, but it looks like a good condenser for the project Leyden. 

> Great regards
> RedIODev

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230220/d3f44f00/attachment-0001.htm>