Interoperability with another DI framework

[Travisnv]

Recently, I started a project with avaje-inject as DI library, it works really well for me on new classes but then when I have a request to reuse a number of rather old libraries with Spring annotations.

I can bring up Spring application context and just use it but I am wondering whether or not can avaje-inject interop with other DI framework which relies on annotation?

I means, in my humble opinion, if we can interop from avaje-inject side, it will open a whole new door for avaje-inject adoption.

[SentryMan]

We do have a @Component.Import annotation used for generating DI for external classes, so I suppose when it comes to just DI we have that covered.

[Travisnv]

Oh, does it drills deep down on class hierarchy?

I havent used the annotation but just imagine probably we have to manually pick names right?

[Travisnv]

Also, you may hint to my hidden objective when I am thinking about reusing some Spring projects on avaje-inject too.

[SentryMan]

Basically, it behaves as if you yourself annotated the class with Avaje's Component annotation.

[SentryMan]

are your old libraries using any spring-specific features?

[Travisnv]

Thanks @SentryMan , from your perspective, is there any drawback we don't generated DI for annotated classes from another DI framework?

Avaje-inject possibly covers 90-95% user cases for simple annotated classes I think.

[SentryMan]

Things might start a little slower since spring still uses reflection/class path scanning.

[Travisnv]

I means, why avaje-inject doesn't process Spring annotations and generate DI classes for them? Any difficulty in doing such task? The trade of longer build time Vs faster startup is really a winning point for avaje-inject.

For my small projects, I can see that avaje-inject is 3x-10x faster than Spring container.

[SentryMan]

Avaje uses annotation processing to generate DI, so it is entirely unable to detect spring's autoconfiguration classes (annotation processing only works on the current project). We have our own methods of auto-configuration via the import annotation and Module and Plugin systems we have.

Another issue is that spring's configuration bean methods are not public, so even if we could read the classes, we couldn't extract the beans at runtime.

In short, despite having similar annotations, Avaje works completely differently to spring, so a full integration is impossible.

We're closer to dagger than spring I'm terms of implementation, it'd be easier to adapt dagger/guice than spring.

The trade of longer build time

I doubt the build time is extended that much, Java is pretty fast at compiling, even with apt. Using GraalVM is another story though.

[SentryMan]

What I usually do is find an equivalent library in the ecosystem that performs a similar functionality to a spring equivalent. For example, instead of using spring MVC, I might use avaje-http with Javalin/Helidon to build rest services.

Or else if I need to do a database thing, I might use Ebean or JDBI instead of spring data.

[rob-bygrave]

avaje-inject doesn't process Spring annotations and generate DI classes for them? Any difficulty in doing such task? The trade of longer build time Vs faster startup is really a winning point for avaje-inject.

Just to say, as I see it the alternative approach is for a project currently using Spring DI to convert over to avaje-inject is to search and replace from the spring annotations to the avaje-inject / Jakarta.inject annotations.

As I see it, this is more explicit and removes dependencies from the classpath / module-path which to me is important. To migrate over to avaje-inject but then still require lots of spring dependencies in the classpath is not a great win as I see it.

Spring-data for an example.

spring-data is unlikely to be a motivator for me personally - I have been aiming for a different destination for quite a long time so spring-data isn't where I'm heading to or choosing.

Did I understand correctly that you are really wanting to use avaje-inject with spring-data? A specific module in spring-data in particular?

[SentryMan]

I'm under the impression that he's got internal libraries that use Spring that he still wants to use.

[Travisnv]

@rob-bygrave , spring-data is an example for custom artifacts I pull from artifactory. They may have all kind of Spring related stuffs. But as I replied to @SentryMan , there are mainly two groups of them:

• type 01: a complex class hierarchy which purely DI, not spring specific.
• type 02: a mixture of reused code from Spring sub project. THey can also be mixed with Spring auto configuration dependency for a certain libraries where they support Spring auto configuration. Those classes usually have some extra custom logic.

About: search and replace annotations to completely move to avaje-inject is an option to pick but I think for large scale project, it might require huge amount of testing to confirm the move is safe. For this reason, I have this thread since I haven't seen any DI library can offer such capability to Spring framework. Hope this help to clarify the reason I post this question. Let's say, we have an intelligent DI who understand other DI library / framework and can control it for the application.

One curious question: what is "different destination" which you mentioned above?

[rob-bygrave]

type 01: a complex class hierarchy which purely DI, not spring specific

I don't know of any issue avaje-inject has here per say.

type 02: a mixture of reused code from Spring sub project

Ultimately my goal for avaje-inject is not to improve an existing spring app with many spring dependencies. Other people might try to do something here for that but I don't see that ever being my focus or putting my time and effort into that.

but I think for large scale project, it might require huge amount of testing to confirm the move is safe

Interoperation with Spring-DI really isn't a goal of avaje-inject so I don't see people migrating "large" Spring apps to use avaje-inject but instead adopt it for smaller newer things. It really depends on the specific dependencies as I see it.

spring-data ... "different destination"

I am the creator of ebean orm. Given a choice, I do not choose to use spring-data for database access.