[Maybe] Option for merged modules to automatically declare uses for existing provides

[crschnick]

I'm using the following configuration:

extraJavaModuleInfo {
    module("io.modelcontextprotocol.sdk:mcp-core", "io.modelcontextprotocol.sdk.mcp") {
        mergeJar("io.modelcontextprotocol.sdk:mcp-json")
        mergeJar("io.modelcontextprotocol.sdk:mcp-json-jackson2")
        overrideModuleName()
        exportAllPackages()
        requires("com.fasterxml.jackson.core")
        requires("com.fasterxml.jackson.databind")
        requires("com.fasterxml.jackson.annotation")
        requires("org.slf4j")
        requires("reactor.core")
        requires("org.reactivestreams")
        requires("com.networknt.schema")
    }
}

I would have expected the module to automatically declare the uses entries as it does for provides entries for the same module. But it doesn't, I have to add

        uses("io.modelcontextprotocol.json.McpJsonMapperSupplier")
        uses("io.modelcontextprotocol.json.schema.JsonSchemaValidatorSupplier")

manually. Is this expected or can this be improved?

[crschnick]

For io.modelcontextprotocol.sdk:mcp-core:0.13.0 that is, for reproducibility

[jjohannes]

Hi @crschnick. Yes this is expected.

If the io.modelcontextprotocol libraries had proper JPMS support, the module-info.class of io.modelcontextprotocol.sdk:mcp-json would need to contain the uses declarations you added. Because code in the module – McpJsonMapperSupplier and JsonSchemaInternal – uses Java's ServiceLoader with these interfaces.

If the libraries are used on the class path, without module-info.class, there is no concept of uses. There, any code is allowed to load services of a certain interface no matter in which Jar it is located as there are no "module boundaries". See also Javadoc of ServiceLoader for differences of Module Path and Class Path service loading.

As a consequence, the uses is declared nowhere when there is no module-info.class file. Hence, there is no place this plugin could obtain the information from.

[crschnick]

The point I was trying to make is that in the specific case of a merged module, the plugin could obtain the information because another jar that was merged into the module declared the provides info for a class contained in the original jar. I don't see any scenario in which you don't want to automatically add a uses as well in this case

[jjohannes]

There is no guarantee that the interface/class of a uses statement is declared in the same Module as the uses statement itself. For example, if you have a central "DataModel/API" Module, it may declare and export only the interfaces which are then used by another module that contains the central application with the loading mechanism (declares uses) and other Modules that provide the implementations (declare provides).

In the merging scenario, you may then end up merging only the "DataModel/API" Module, but not the Module doing the loading. Maybe it's unusual, but you never know. If you are in a situation where you need to merge, the Module structures are already "weird".

I think, the only way to 100% automatically determine if a uses needs to be added would be to understand the code that calls ServiceLoader.load. Event if we would attempt do that – which I think is out of scope – it cannot always be statically determined which services are loaded, as you could implement a generic service loading that does not work with the Module System at all (as in this example langchain4j/langchain4j#3668).

[crschnick]

Ok, technically this is correct then. But I would argue that in 90% of merged modules, this would make the life easier. Because right now it forces me to look up if there are any service providers used across multiple jars that are merged together in the end.

Maybe it would make sense to add an option to automatically declare uses for merged modules where provides statements for an existing class in the merged module are found? That way, you can cover both cases and it would make the life easier with the option enabled, which would apply for the majority of cases. Of course, the option would still have to be explicitly enabled by the user.

[jjohannes]

Yes an opt-in option for this can be added. I think this should probably have a similar place/syntax as other options such as exportAllPackages(). It would then also work when you do not merge. I would do that for consistency of the options, not because I have a concrete use case.

To clarify what this would do:

• There would be an option like this:

module("io.modelcontextprotocol.sdk:mcp-core", "io.modelcontextprotocol.sdk.mcp") {
  declareUsesForAllDeclaredServiceProvider()
  ...
}

• If declareUsesForAllDeclaredServiceProvider() is set, uses statements are added for all provides declared in the transformed Jar
• Notes on implementation - it's probably enough to...
  • add the option in parallel to how the other options work
  • Add a visitUses here for each visitProvide (if option is set)

@crschnick do you agree with that? Would you be interested to prototype this and test that it works as expected in your case?

A PR would be welcome.