Inconsistency with service loading by layer or by class loader

[David Lloyd]

On Thu, Dec 12, 2024 at 7:27 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> If ServiceLoader.load is invoked with a ClassLoader then it lazily
> iterates through the class loader delegation chain. If ServiceLoader.load
> is invoked with a ModuleLayer then it iterates through the module layers.
> The former has deliberately limited support for cases where a class loader
> is used by a module layer but doing what you propose is adding more
> complexity for what seems like a really niche usage. I would worry that
> changing it along the lines you propose would result in something that only
> a few people could understand.
>
> Have you looked at changing these frameworks to work with modules and
> specify a module layer to ServiceLoader.load?
>

The problem is that 100% of these frameworks are required to work on the
class path as well (and some are not yet being tested on the module path,
or even defining an automatic module name, though I've been working to
improve that for a couple years now). So, we'd need some kind of
non-trivial fallback logic to try both the correct layer (if any) or the
correct class loader (since the unnamed module has no layer). Also note
that "correct" depends on the framework: some are using the caller, some
are using the TCCL, some are using their own class loader, some are using a
configured class loader, etc. It also would likely involve deduplication of
returned services along with coping with ordering, which is sometimes
significant. I think it's unlikely that we would be able to settle on a
preferred pattern for this, and even more unlikely that we would be able to
successfully push these changes to *all* Jakarta, Microprofile, etc. spec
APIs in addition to non-spec APIs (even the ones that Red Hat "controls"
would probably give resistance unless the change was really clean/simple).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241212/0ae06657/attachment.htm>