On 23 Apr 2023, at 00:49, Josiah Noel
<josiahn...@gmail.com<mailto:josiahn...@gmail.com>> wrote:
How would this solve the issue? I can't see how having a second module on the
same jar/artifact would work for this case.
Here's how I envision it. In Jar Y, we'd have two modules.
module y {
exports y.pkgs;
}
and in the second module, we would have the SPI impl class
module y.inject {
requires static x;
provides x.plugin with y.inject.PluginImpl;
}
Almost. Module y.inject `requires x`, not `requires static x`. If x is not
required by any resolved module, there can be no resolved module that `uses
x.plugin`.
Now say some project adds the X Jar and the Y jar, the modules should resolve
and X should service load the SPI from the y.inject module.
Instead of a second module my gut says that what would solve this is a:
'provides static'
I'd like this too, but I don't think it's gonna happen.
There’s no need for that if you can get the desired behaviour without it. Since
the difficulty is the number of artefacts rather than the number of modules, a
multi-module JAR is a more elegant solution, as it doesn’t require a new
construct.
— Ron
