Inconsistency with service loading by layer or by class loader

[Alan Bateman]

On 13/12/2024 23:57, David Lloyd wrote:
> :
>
> Another behavioral quirk is that service loaders don't actually work 
> the same if the service was found in a named module. If a service 
> provider class was found in a named module, then the loader will also 
> look for a `provider` static method which can return the service 
> instance, whereas services found via the classic mechanism will only 
> invoke the constructor of the service class to acquire its instance. 
> Additionally, the classic `META-INF/services` mechanism is still used 
> in module mode, however the service provider classes are filtered out 
> if they are found to be located in a named module after loading the 
> class. Since behavior differs between module and non-module mode, a 
> library author which seeks to run in both environments while using 
> ServiceLoader has to carefully consider how services might be loaded 
> in a given environment.

I have some sympathy to the complaint that service providers deployed as 
a module can define a static provider method or public constructor 
whereas service providers deployed on the class path must define a 
public constructor.  The resolution of issue #ServiceLoaderEnhancements 
[1] in JSR 376 did not propose to change existing behavior. Maybe that 
specific ask could be looked at again but it would require great care.

On "the classic META-INF/services mechanism is still used in module 
mode". I think you mean that creating ServiceLoader with a class loader 
may locate META-INF/services configuration file in a named module. 
Resources in META-INF/** are not encapsulated and it wouldn't be 
surprising for a modular JAR declaring a service to also have a 
META-INF/services configuration file for use on the class path. This is 
the reason for the filtering, but it shouldn't be observable unless the 
configuration file lists the name of a class that is not in the JAR file 
(an anti-pattern is detected as packaging file) or is out of sync with 
the module declaration. There is more than can be done at packaging time 
to detect such mistakes [2].

-Alan.

[1] 
https://mail.openjdk.org/pipermail/jpms-spec-experts/2016-September/000395.html
[2] https://bugs.openjdk.org/browse/JDK-8207339

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241215/e776b7a2/attachment-0001.htm>