When using Kotlin, mutable super-class's properties are not bound when a sub-class declares a non-default primary constructor that does not cover the super-class's properties

[vominhtri231]

I have a spring boot - Kotlin project, which I am upgrading from Spring 5, Java 8 to Spring 6, Java 21

build.gradle.kts

plugins {
    kotlin("jvm") version "2.1.20"
    id("org.springframework.boot") version "3.4.4"
    id("org.jetbrains.kotlin.plugin.spring") version "2.1.20"
    id("io.spring.dependency-management") version "1.1.7"
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter")
    implementation(kotlin("reflect"))
}

MyProperties.kt

@ConfigurationProperties(prefix = "my.test")
@Component
class MyProperties {
    var customs: List<CustomA> = listOf()
    var bases: List<Base> = listOf()

    open class Base(
        var type: String = ""
    )

    class CustomA(
        var y: String = "",
        var z: String = "",
    ) : Base()
}

Run the application by bootRun task, with these env variables:

MY_TEST_BASES_0_TYPE=value4;MY_TEST_CUSTOMS_0_TYPE=value3;MY_TEST_CUSTOMS_0_Y=value1;MY_TEST_CUSTOMS_0_Z=value2

I would expect that the myProperties.customs[0].type would return value3, but it would return an empty string instead.

The problem only happens if the kotlin("reflect") dependency exists and does not occur in Spring 5, Java 8.

It looks like the base class's properties are not bound at all. If I modify the MyProperties class as this, the type property will bind correctly

open class Base(
   open var type: String = ""
)

class CustomA(
   override var type: String = "",
   var y: String = "",
   var z: String = "",
) : Base()

[philwebb]

Could you please provide a complete sample application that works with earlier version and fails with the later one. Please either attach a zip file or provide a link to a GitHub project.

[vominhtri231]

Here is the Github project that indicates the problem: https://github.com/vominhtri231/PropertyNotMap

[quaff]

I confirm it's a regression.

The Binder in v2.7.8 instantiate CustomA with default constructor parameters, then bind properties via setters (include setters from super classes).
The Binder in v3.4.4 instantiate CustomA with provided configuration properties, no setter invoked later, I think invoking setters in super classes should fix it, GH-42276 is related.

[wilkinsona]

The change in behavior is due to 3.0 switching to implicit constructor binding.

The Kotlin class has two constructors (CustomA() and CustomA(String, String)). Viewed from Java, this class isn't eligible for constructor binding as it has two constructors and neither is annotated with @ConstructorBinding. When the kotlin("reflect") dependency is present, this allows Kotlin's primary constructor to be identified. It's CustomA(String, String) and it's incorrectly identified as being suitable for constructor binding.

@vominhtri231, we'll see what we can do to get this working out of the box. In the meantime, there are a couple of ways in which you can work around the change in behavior.

You can use @Autowired to indicate that the constructor should not be used for property binding:

@ConfigurationProperties(prefix = "my.test")
@Component
class MyProperties {
    var customs: List<CustomA> = listOf()
    var bases: List<Base> = listOf()

    open class Base(
        var type: String = ""
    )

    class CustomA @Autowired constructor(
        var y: String = "",
        var z: String = "",
    ) : Base()
}

Alternatively, you can declare the class with only a default constructor:

@ConfigurationProperties(prefix = "my.test")
@Component
class MyProperties {
    var customs: List<CustomA> = listOf()
    var bases: List<Base> = listOf()

    open class Base(
        var type: String = ""
    )

    class CustomA : Base() {
        var y: String = ""
        var z: String = ""
    }
}

I think invoking setters in super classes should fix it

Thanks for the suggestion but this won't restore 2.x's behavior:

• it would affect Java apps and this problem is Kotlin specific
• it wouldn't use the default constructor whereas 2.x does use it
• it will result in some properties being bound twice (once via the constructor and once via setters)