Support java module system (jpms) via Multi-Release jar with module-info - [was Minimum Java 11...]

[rbygrave]

Originally this was:

Minimum Java 11 - make avaje-inject Java 11+ (from Java 8+)

[norrisjeremy]

I'm curious to understand why you're considering making it require a minimum of Java11?

[rbygrave]

In theory:

• We can make in jpms aware / add a module-info.java which increases the required discipline on avaje-inject in terms of dependencies and what is public
• I don't really consider Java 9 or Java 10 to be preferred. I think Java 11 is the next target after 8 being somewhat a LTS version
• I have a Kubernetes/Docker deployment bias so as I see it Java 11 is an minimum runtime

In reality I'm not sure if this is a great idea yet. I don't know when libraries should bump up from Java 8 but I think we will have to do it at some point so when ... (personally and for the places I work they are all Java 11+).

Hmmm.

[norrisjeremy]

From what is an admittedly selfish desire, I would prefer to see that it remain Java8 compatible for now, since we still have several projects that still need to maintain Java8 compatibility unfortunately.

For JPMS compatibility, I think it may be possible to use the moditect-maven-plugin to generate the module-info.class file without fulling moving everything to Java9+ (although I've not fully investigated this particular Maven plugin to confirm).

It's also not especially difficult to build a multi-release jar in order to add Java9+ features. I've done it for the JSch fork to add support for new crypto algorithms that are available in Java11 & Java15, while keeping the base jar file fully Java8 compatible. It involved adding a few extra execution sequences for maven-compiler-plugin & maven-resources-plugin, and then having the maven-jar-plugin add the multi-release attribute to the manifest.

But I understand if you want to avoid adding these sorts of complexities and decide to move to purely requiring Java11+.

[rbygrave]

PR for JPMS compatibility via moditech-maven-plugin ... #59

[rbygrave]

For myself with JPMS we need to explicitly register the BeanContextFactory (which is kind of nice) with a provides clause like:

module junk {

  requires io.avaje.inject;

  provides io.avaje.inject.core.BeanContextFactory with org.example._di$Factory;
}

... with jpms developers need to know about and find the BeanContextFactory interface. My gut says it would be nicer if BeanContextFactory was in the io.avaje.inject package (and perhaps the generated _di$Factory should instead be called _di$BeanContextFactory. Hmmm.

Edit: Updated the example module code.

[norrisjeremy]

... with jpms developers need to know about and find the BeanContextFactory interface. My gut says it would be nicer if BeanContextFactory was in the io.avaje.inject package (and perhaps the generated _di$Factory should instead be called _di$BeanContextFactory. Hmmm.

I think you may be right that it would be better for BeanContextFactory to be in io.avaje.inject. Then I think you wouldn't need to export the io.avaje.inject.core package.

[rbygrave]

wouldn't need to export the io.avaje.inject.core package

There are things in core used by the generated code like BeanLifeCycle, Builder etc. So those need to be in an exported package.

I think the options are something like:

• move BeanContextFactory to io.avaje.inject (it references Builder interface which is in core but maybe that is ok)
• rename io.avaje.inject.core to say io.avaje.inject.spi (Is spi a better package name? ... more expected?)
• move everything in core into io.avaje.inject (I don't like that option, core has code the generated code needs but otherwise is "detail")

Hmmm.

[norrisjeremy]

I think the options are something like:

• move BeanContextFactory to io.avaje.inject (it references Builder interface which is in core but maybe that is ok)
• rename io.avaje.inject.core to say io.avaje.inject.spi (Is spi a better package name? ... more expected?)
• move everything in core into io.avaje.inject (I don't like that option, core has code the generated code needs but otherwise is "detail")

Hmmm.

Hmm, it may be more hassle than it's worth to move BeanContextFactory now that I look more closely.
It appears that DependencyMeta, BuilderFactory & Builder would also need to be moved, since it looks like they are all used by the generator as well (both directly and in the code it generates in consumers).

[rbygrave]

more hassle than it's worth to move BeanContextFactory now that I look more closely

I think the same.

I'm probably leaning toward renaming core package to spi - mostly as a gut feel really with "core" sounding a bit too implementation orientated to me. It hasn't mattered in classpath world but once people are explicitly putting the provides clause in module-info core doesn't look right to me.