4.x: Pico generated module-info.java has redundant uses

[tomas-langer]

Pico - generates uses and provides, even though it does not. uses should only be explicitly defined if the service loader is used from that module, provides is only to declare that the module implements a service provider interface loaded using service loader.

Example from a test (pico/tests/resources-pico/src/test/resources/expected/module-info.java._pico_):

    uses jakarta.inject.Provider;
    uses io.helidon.pico.tests.plain.interceptor.IA;
    uses io.helidon.pico.tests.plain.interceptor.IB;
    // Pico application - Generated(value = "io.helidon.pico.tools.ApplicationCreatorDefault", comments = "version=1")
    provides io.helidon.pico.api.Application with io.helidon.pico.tests.pico.Pico$$Application;

[trentjeff]

From my reading (see below) it seems to me it is slightly more than this.

• https://stackoverflow.com/questions/45777949/whats-the-purpose-of-uses-directive-in-java-9 (this is the main one)
• https://www.baeldung.com/java-9-modularity

Practically speaking, however, it is really impossible for us to know what is Service Loaded and what is not. The heuristic that is in use right now will look at the externalContracts that each service declares. External contracts are interfaces declared in module A, and advertised from module B. These ultimately generate a 'uses clause'.

For example:

public class FallbackInterceptor$$Pico$$Activator
            extends io.helidon.pico.runtime.AbstractServiceProvider<FallbackInterceptor> {
    private static final DefaultServiceInfo serviceInfo =
        DefaultServiceInfo.builder()
            .serviceTypeName(io.helidon.nima.faulttolerance.FallbackInterceptor.class.getName())
            .addExternalContractsImplemented(io.helidon.pico.api.Interceptor.class.getName())
            .activatorTypeName(FallbackInterceptor$$Pico$$Activator.class.getName())
            .addScopeTypeName(jakarta.inject.Singleton.class.getName())
            .addQualifier(io.helidon.pico.api.DefaultQualifierAndValue.create(jakarta.inject.Named.class, "io.helidon.nima.faulttolerance.FtFallback"))
            .declaredWeight(60.0)
            .build();

The Pico code-generated interceptor (in module B) implements the Interceptor contract (from module A).

Fwiw, Interceptor is declared to be a @Contract since the Pico service implementation will need to lookup interceptors. However, all of Pico relies on ModuleComponents being service loadable but not the contracts themselves. So we can definitely remove the @Contract declaration (and the uses) will/should fall off. But doing so will also make these Interceptors not able to be looked up from the Services registry.

The bottom line here is I think Pico is erroring on the side of safety since it doesn't really know what is Service Loaded. If you have a suggestion for a better heuristic then LMK.

[tomas-langer]

uses in module info is strictly for usages of Java ServiceLoader.
Contract or ExternalContract does not imply it is a ServiceLoader provider interface.

[trentjeff]

Per discussion offline w/ @tomas-langer , he suggested to remove the uses. The net is that while the uses is not harmful, it is not proper to have regardless. Since Pico has no way to know if a contract is service loaded, then this must be the responsibility of the developer to manually add and it can therefore not be implicitly generated.