[External] : Re: Inconsistency with service loading by layer or by class loader

[Alan Bateman]

On 17/12/2024 14:21, David Lloyd wrote:
> :
>
>
> However, to give a counter-example, `Module` has `addUses` as well. 
> But if I want to call `addUses` on behalf of a module I've defined, 
> there is no corresponding `ModuleLayer.Controller` method so I do have 
> to define the extra class, and that's a bit silly. This is an example 
> of an easy enhancement that would not affect the integrity of the 
> platform, would not significantly increase maintenance burden (since 
> the logic would be nearly identical to its sibling methods), and would 
> be easy to achieve.
>

Module::addUses is for cases where code may need to create a SL that 
loads a service that wasn't known to this module at compile time.

ML.Controller is the equivalent of the --add-exports, --add-opens, 
--add-reads command line options for the boot layer. There was little 
motive to work through the implications of --add-uses and --add-provides 
and the ML.Controller equivalents at the time. The exception is the 
agent case where instrumentation may augment the services used (or 
provided).

Time has passed and I can only think of one request for --add-uses has 
come up. That request didn't go very far because service binding 
augments the module graph during resolution. A CLI option (or 
ML.Controller equivalent) can only work reflectively, which is 
post-resolution. This is of course too late for what the group 
requesting this wanted. It hasn't been re-examined since then at least 
not to my knowledge.

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