moditect VS avaje-inject

And then you have to use moditect to generate a module-info.java and this is again because the annotation processor will pick up the provides Processor with YourAnnotationProcessor.

Maybe you've somehow missed https://maven.apache.org/plugins/maven-jlink-plugin/ https://github.com/moditect/moditect https://github.com/beryx/badass-jlink-plugin https://github.com/sormuras/testing-in-the-modular-world

Yes, you are right. jlink does not work with automatic modules. But using that plugin https://github.com/moditect/moditect you can easily transform almost any java library into a named module. It is a shame there are libraries under development, that have not been adapted to the java modular system.

FWIW, I've had a lot more issues with reflective access when using GraalVM. Reflection is mainly a problem with modules if you forget to 'open' your modules which is easy to fix in many cases. There's also moditect if the library author still doesn't want to learn how to include a module-info in the legacy compatible jar.

Thanks. I don't think iText has a modularized jar. Would it be possible to inject the modules into my jar, as per: https://stackoverflow.com/questions/47222226/how-to-inject-module-declaration-into-jar . Or maybe use moditect?

Or apply the https://github.com/moditect/moditect plugin and keep the build in JDK8. Let the plugin create the module descriptors without configuring JDK toolchains.

You can use the https://github.com/moditect/moditect maven plugin to add the module-info to the third-party jars

The next solution, which is the one I'm writing about. Is to modularize foo's jar, this is easily accomplished using the moditect plugin. But it can be tricky since I don't have, nor do I need, bar, and I prefer doing most of the work in build time and not manually.

It's possible to add this information during one's build even though the procedure is error-prone and boring. The description on how to achieve this deserves a post on its own. For more information, please check this Oracle magazine article. Suffice to say here that it makes heavy use of the Moditect Maven plugin.

Avaje Inject has quickly become one of my favorite libraries. Inject is basically like Dagger if Dagger was focused on server side instead of Android. It's a tiny lib (~76kb) that uses the power of annotation processing to generate DI classes. Recently I've been using it for AWS lambdas and it works pretty great.

https://avaje.io/inject/ - Implements JSR-330 and JSR-250

Have you tried out Avaje inject? It's currently my favorite DI lib.

Been building a web service with avaje inject and avaje http lately. It has a very spring-like feel for a DI lib, (Lifecycles, Test annotations) but the libs are tiny and totally reflection free through codegen.

Avaje is pretty cool, it's a compact DI library based on APT. https://github.com/avaje/avaje-inject

Like avaje inject ? DI as source code generation done at build time?

Just to say, I also created a DI library called avaje-inject - https://avaje.io/inject/ ... which uses Java annotation processing to do DI as mostly source code generation. So the runtime dependency is ~ 67Kb. It also supports AOP aspects via source code gen which I think is kind of cool - you can have your own aspects like `@Retry` etc and it's actually done using source code generation.

I am a bit fan of using annotation processing (source code generation) to simplify things - DI https://avaje.io/inject/ , JSON binding (https://github.com/avaje/avaje-jsonb) and rest servers and clients (https://avaje.io/http).

Dagger2 and avaje-inject are other options (DI as source code generation via annotation processing). https://avaje.io/inject/