@ConfigMapping fails with default function implementations in interfaces in Kotlin projects

[Shpota]

If an interface annotated with @ConfigMapping has a default function implementation the application fails on startup.

Actual behavior

2021-10-01 12:52:36,571 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile dev): io.smallrye.config.ConfigValidationException: Configuration validation failed:
        java.util.NoSuchElementException: SRCFG00014: The config property server.server-url is required but it could not be found in any config source
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:838)
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:794)
        at io.smallrye.config.ConfigMappings.mapConfiguration(ConfigMappings.java:54)
        at io.smallrye.config.ConfigMappings.registerConfigMappings(ConfigMappings.java:36)
        at io.quarkus.arc.runtime.ConfigRecorder.registerConfigMappings(ConfigRecorder.java:81)
        at io.quarkus.deployment.steps.ConfigBuildStep$registerConfigClasses-2116437784.deploy_0(ConfigBuildStep$registerConfigClasses-2116437784.zig:132)
        at io.quarkus.deployment.steps.ConfigBuildStep$registerConfigClasses-2116437784.deploy(ConfigBuildStep$registerConfigClasses-2116437784.zig:40)
        at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:612)
        at io.quarkus.runtime.Application.start(Application.java:101)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:101)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
        at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:98)
        at java.base/java.lang.Thread.run(Thread.java:832)

How to Reproduce?

1. Generate a Quarkus project with Kotlin, Gradle, and yaml.
2. Replace application.properties with application.yml with the following content:

server:
  host: "localhost"

3. Create a ServerConfig interface with the following class:

@ConfigMapping(prefix = "server")
interface ServerConfig {
    fun host(): String

    fun serverUrl(): String = "https://${host()}"
}

4. Run: ./gradlew quarkusDev and observer the error.

Quarkus version or git rev

2.2.3.Final

[quarkus-bot]

/cc @evanchooly

[radcortez]

@evanchooly do you know how can we tell if a method has been implemented on Kotlin? In this case, when we look into the method, it shows as abstract so we think that is not implemented and we add it as a configuration item.

[Shpota]

@radcortez the bytecode of the Kotlin interface that I posted would look somewhat like this in Java:

public interface ServerConfig {
    String host();
    
    String serverUrl();
    
    public static final class DefaultImpls {
        public static String serverUrl(ServerConfig config) {
            return "https://" + config.host();
        }
    }
}

[radcortez]

Thanks. Let me have a look.

[evanchooly]

Have what you need @radcortez ?

[radcortez]

Have what you need @radcortez ?

Maybe. I'll need to adjust the code to look for this and ignore the method. Is this the only way that Kotlin provides the implementation? I was looking into https://youtrack.jetbrains.com/issue/KT-4779

[evanchooly]

what bytecode are you seeing that's problematic, exactly?

[radcortez]

what bytecode are you seeing that's problematic, exactly?

No problem at all so far. It is clear. I'm only concerned about the different ways that it behaves depending on the compiler flags, but I'm guessing that we can just ignore that and provide the bridge to the generated defaults if one exists.