Java extensibility and JPMS (ServiceLoader)

[Josiah Noel]

>
> Note that there was a relative long discussion about this exact topic in
> April 2023:
>

Should multi-module jars be implemented, most issues with problem 2 would
be resolved without needing to resort to circular dependencies or requiring
the user to remember a bunch of extra service modules. Most apps deploying
as a jar would have the optional services work essentially as if they were
on the classpath. The one exception to this case I've found is that
applications deployed as fully modular jlink runtime images require the
optional service modules to be explicitly defined in the module-info or
added to the jlink command. (which is a pain for me, as I like using
jlink to add my application modules to the runtime)

This too I've had to deal with by scanning the module info in the processor
and giving compiler warnings if a service is detected in the processing
environment and not specified in the module-info. It's unfortunate though
that this limitation will continue to exist.

While I did also run into this issue, I would favor a solution during the
> build phase. Maybe some project still uses Java 8, where the JDK does not
> yet know about the module-info. The behavior should not change between
> different versions of the runtime.


Well, Helidon's baseline is now JDK 21, so Java 8 compatibility shouldn't
be a concern. I still think that auto-generating service files with an
annotation processor is the way to go if an alternative easier solution
cannot be found in this discussion.

On Sat, Jan 20, 2024 at 8:19 PM Johannes Spangenberg <
johannes.spangenberg at hotmail.de> wrote:

> *Ad 2 - Provider module cannot be optional dependency*
> -------------------------------------
> Problem: We cannot declare `requires static` on a module that has the
> ServiceLoader provider interface (or abstract class)
>
> Note that there was a relative long discussion about this exact topic in
> April 2023:
>
> https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/014846.html
>
> I personally think that the current implementation is too restrictive as I
> see very little gain in this runtime error, but there was also a noticeable
> opposition.
>
> *Ad 4 - Duality of definition between classpath and module path*
> -------------------------------------
> Problem: To support services, we MUST declare them twice - once in
> `provides` in module-info.java, once through META-INF/services
> Possible solution: Java could read module descriptors even when running in
> classpath mode to add service implementations and merge it with
> META-INF/services information
>
> While I did also run into this issue, I would favor a solution during the
> build phase. Maybe some project still uses Java 8, where the JDK does not
> yet know about the module-info. The behavior should not change between
> different versions of the runtime.
>
> PS: I am not affiliated with the project, besides being subscribed to this
> mailing list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20240120/78aedf90/attachment-0001.htm>