On 12/12/2024 14:35, David Lloyd wrote:
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).
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
