On Thu, Dec 12, 2024 at 7:27 AM Alan Bateman <alan.bate...@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
