`requires static` versus service binding

[Christian Beikov]

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.bursie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20250113/7ce13ee3/attachment.htm>