Inconsistency with service loading by layer or by class loader

[Alan Bateman]

On 12/12/2024 14:35, David Lloyd wrote:
> 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).
>
This comes across as a soup of complexity. I can't help thinking it 
would be much simpler to use module layers as originally envisaged, 
meaning each configuration/layer layer is a graph of modules with a 
single parent. Whether the modules are mapped to a single class loader 
or different class loaders should just work. Existing code that uses 
ServiceLoader with a class loader would have a much better chance of 
working in that scenario.

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