> > 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.spangenb...@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. >
