Hi,
just wanted to say that I have also run into this issue recently when
introducing module-infos in Blaze-Persistence.
Having to use `requires` instead of `requires static` when also wanting
to provide a service is really unfortunate. Either I have to split the
module and make the setup harder for users or impose potentially
unnecessary dependencies onto a user application.
Regards,
Christian
Am 13.01.2025 um 16:25 schrieb David Lloyd:
On Fri, Jan 10, 2025 at 11:22 AM Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com> wrote:
On 2025-01-08 22:33, David Lloyd wrote:
Thus I'm inclined to believe that this restriction does not serve
any practical benefit, and I hope it can be reconsideredto be
respecified as a compile-time-only check.
I agree. I was bitten by this as a Java developer in a hobby open
source project, and even if at some point I understood why things
where the way they are, I do not remember the reasoning, and I
still find it confusing that it did not work as I expected it to,
nor what steps I were supposed to take instead to resolve the
problem at hand.
I understand that this is not a very common problem or a
high-priority issue, and I would have accepted that it was
down-prioritized to the point that it will take a long time to
resolve, but the current "works as intended" approach is still a
bit hard for me to swallow.
I think there's a bit of self-selection: this kind of problem mostly
appears in more complex systems; the work to move complex systems to
JPMS is already nonzero; complex systems do not move because of this
kind of problem; therefore, the problem is considered a non-issue
because nobody is complaining about it.
As an experimental workaround I was trimming optional dependencies
from the descriptor at run time and doing a late `addReads` instead if
the dependency is present. This part works fine, however I then also
have to strip out `uses` and sometimes `provides` for this to work if
they correspond to packages in the optional dependency (which is a
check that also incurs a run time cost), and adding those back to the
module late requires hacky workarounds: for `addUses` I have to
generate a class into the target module so that it can call
`Module.addUses` on my behalf, and for `addProvides`, I have to access
private JDK internals thus requiring `--add-exports` of a core JDK
package, which is less than ideal. I did propose a patch to allow
controllers to add these but it was soundly rejected and the ensuing
discussion yielded little of value. So hopefully we can get around it
another way: by allowing `uses` and `provides` of services whose
packages are not present at run time.
--
- DML • he/him
