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
