Document or fix hard dependency on avaje-inject when using module-path

[NoonRightsWarriorBehindHovering]

Hi,

when trying to evaluate avaje i could not help but notice, that there is a hard dependency on avaje-inject, albeit the require static statement in the modules-info.

A MRE can be found here: https://github.com/NoonRightsWarriorBehindHovering/mre-avaje-config-1

The issue is expected as far as i can see, given that the official documentation says this: A module M declares that it 'uses p.S' or 'provides p.S with ...' but package p is neither in module M nor exported to M by any module that M "reads". Source: https://docs.oracle.com/javase/9/docs/api/java/lang/module/package-summary.html

As such without avaje-inject being read by any module explicitely (requires static does not "read", because it it optional), the above fails.

A simple workaround would be to require it in the consuming application. This might not be feasible, when inject is not being used. Alternatively the provides statement could (naively) be moved somewhere else (e. g. a new jar or avaje-inject).

In any case the intended outcome should be documented.

Sorry for opening two bugs already in quick succession. :)

[SentryMan]

Sorry for opening two bugs already in quick succession. :)

You and I have a different definition of quick it seems. In any case, that MRE repo link givers me a 404.

[NoonRightsWarriorBehindHovering]

Sorry about that! I forgot to publish the repository.

[SentryMan]

happens to the best of us

[rbygrave]

The failure being:

$ ./shell.sh
Error occurred during initialization of boot layer
java.lang.module.ResolutionException: Module io.avaje.config does not read a module that exports io.avaje.inject.spi

[SentryMan]

so to be clear, are you getting a module not found exception?

EDIT: ninja'd, it seems I have not built your MRE correctly

[SentryMan]

when I use the mvn compiler plugin, it works without needing inject.

    <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.11.0</version>
          </plugin>
        </plugins>
    </build>

EDIT: ahh, no it doesn't

[rbygrave]

It compiles ... but it gives an error at runtime. We see:

$ ./shell.sh
Error occurred during initialization of boot layer
java.lang.module.ResolutionException: Module io.avaje.config does not read a module that exports io.avaje.inject.spi

[SentryMan]

yeah, I'm still having trouble getting the script to run on my local (with both Windows and MacOS)

[rbygrave]

FYI: I emailed jigsaw-dev and Alan pointed me to - https://bugs.openjdk.org/browse/JDK-8299504

[SentryMan]

@NoonRightsWarriorBehindHovering Yeah, this one might take a while to resolve, thanks for finding this.

[rob-bygrave]

I've posted some thoughts/comments to jigsaw-dev and waiting to see what the response is.

If the angle is "this works in classpath but not in module-path" ... then its a JDK bug in module resolution and specifically module resolution should not fail in the case for a provides p.S with .. when p.S is not in the module-path (just like this does not fail in the classpath case).

---

A potential alternative solution is to invert the relationship by NOT implementing these Plugin API's in avaje-config (and avaje-jsonb) but instead changing avaje-inject to detect the existence of avaje-config (and avaje-jsonb) in classpath/module-path via say Class.forName() and creating the implementations of these Plugin APIs in avaje-inject itself.

Using Class.forName() seems a bit "dirty" and less desirable but I think this should work ok for the avaje-config PropertyRequiresPlugin case [modify how avaje-inject determines the default implementation of PropertyRequiresPlugin].

However, my guts says this approach will not be great for the Plugin & avaje-jsonb case (as we want to determine the types all the plugins provide etc and that looks like it might get 'hacky').

[SentryMan]

However, my guts says this approach will not be great for the Plugin & avaje-jsonb case (as we want to determine the types all the plugins provide etc and that looks like it might get 'hacky').

Yeah, this leaves a bad taste in my mouth.

It'll also make it harder to maintain, suppose we come up with more ideas for more plugins. (like the avaje/hibernate validator and http resolver). Are we just gonna keep modifying inject with Class.forName to add the defaults?

[rob-bygrave]

Are we just gonna keep modifying inject with

I recon we are going to implement our own ServiceLoader.

So avaje-inject will have it's own code that does:

• getResources("META-INF/services/io.avaje.inject.spi.Plugin")
• iterate those resources extracting the implementation class names ...
• use reflection to create new instances
• F#$%ing swear like no tomorrow
• Try to chill ... ponder the universe

Edit:

• I agree that Plugin is just going to be far too common to continue adding to avaje-inject - it isn't a sustainable approach to keep modifying avaje-inject in this manor. So we need our own ServiceLoader that works in both classpath and module-path. I believe code can access all the resources in META-INF/services in module-path without needing specific permissions in module-info.java but we should confirm this first.
• http resolver ... yeah, this will work for that too (and PropertyRequiresPlugin if we desire)

[SentryMan]

use reflection

I'd really prefer not to.

[rob-bygrave]

use reflection

This is what ServiceLoader does under the hood.