Hey how do you all, protect against Binary Compatibility issues in your libs. Let's say your workin...

# library-development

[rkeazor]

Hey how do you all, protect against Binary Compatibility issues in your libs. Let's say your working with DataClasses in a library module which is a known culprit of this . But you know that data class may grow in properties over time, what would be the best course of action to prevent binary compatibility?

[Tijl]

do you know about https://github.com/Kotlin/binary-compatibility-validator ?

[Drew Hamilton]

I made Poko to help with this – it doesn't generate copy or componentN functions so you don't have to worry about their compatibility. You still have to keep track of constructor compatibility though, which I use the tool linked above for.

[rkeazor]

but how do yall normally resolve constructor compatibility. Do youj just create secondary constructor?

[Drew Hamilton]

Yeah. Alternately you could make the constructor private and write a builder.

[ephemient]

if you've already exposed data classes publicly and want to maintain binary compatibility, your only options are to never change them or to convert them to non-data classes with manual additions for compatibility if you do need to change them

[ephemient]

Kotlin's builder pattern is a bit different than Java's, for example

Json {
    coerceInputValues = true
    ignoreUnknownKeys = true
    isLenient = true
}

and not

OkHttpClient.Builder()
    .connectTimeout(1, SECONDS)
    .writeTimeout(1, SECONDS)
    .readTimeout(1, SECONDS)
    .build()

but the former is a bit less ergonomic to use from Java, if you're concerned about that

[mbonnin]

We had data classes in an early version of our lib, we moved everything to Builders for that reason

[rkeazor]

will kotlin DSL work as well @mbonnin @ephemient

[mbonnin]

Not if you want java interoperability

[rkeazor]

oh ok , but if its pure kotlin code , it will be fine ?

[mbonnin]

Yep, for Kotlin callers it should be fine