On Tue, Dec 17, 2024 at 10:57 AM Alan Bateman <alan.bate...@oracle.com> wrote:
> 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. > I was using it as more of an example about how a thing may be possible and allowed by the platform, and thus is achievable, yet not specifically presented with a convenient API. That said, I've opened https://bugs.openjdk.org/browse/JDK-8346439 as a way to continue the discussion, framed as a specific feature request which covers what we need, and it does in fact include an `addUses` method. Hopefully the conversation there will be more productive, being based on specific capabilities rather than hypotheticals. -- - DML • he/him
