<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 13/12/2024 23:57, David Lloyd wrote:<br>
<blockquote type="cite" cite="mid:CANghgrRU3mb9RynUEji6Pg8q5tXktPFWJrY-8Opzhi-nfiPQPg@mail.gmail.com">
<div dir="ltr">:<br>
<div class="gmail_quote gmail_quote_container">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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].<br>
<br>
-Alan.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/jpms-spec-experts/2016-September/000395.html">https://mail.openjdk.org/pipermail/jpms-spec-experts/2016-September/000395.html</a><br>
[2] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8207339">https://bugs.openjdk.org/browse/JDK-8207339</a><br>
<br>
<br>
</body>
</html>