Inconsistency with service loading by layer or by class loader

[David Lloyd]

On Sun, Dec 15, 2024 at 1:22 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

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

Sure, I think that is worth pursuing separately. It is very rare that a
library can or will take advantage of this mechanism today because the
class path and plain class loading is still very widely used today, and as
I said, library authors are generally not keen to exclude any part of their
possible audience.

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

>From tracing through the JDK code, I believe the filtering was happening
after each listed class was loaded, so that (for example) if one class was
found in a named module, and one was in an unnamed module, only the class
found in a named module would be filtered out, but yes, that is the
mechanism I'm referring to (though mainly just for completeness).
-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241216/ded14253/attachment.htm>