Skip to content

Instantiate Kotlin data classes using the _primary_ constructor#2933

Closed
jawo-a wants to merge 1 commit intomapstruct:mainfrom
jawo-a:kotlin-components
Closed

Instantiate Kotlin data classes using the _primary_ constructor#2933
jawo-a wants to merge 1 commit intomapstruct:mainfrom
jawo-a:kotlin-components

Conversation

@jawo-a
Copy link

@jawo-a jawo-a commented Jul 11, 2022 •
edited
Loading

A lot of Kotlin projects define DTOs using data classes with optional parameters like

data class Person(
    val name: String? = null,
    val email: String? = null
)

Unfortunately these data classes do not work with MapStruct because the Kotlin compiler generates multiple constructors under the hood.
Issues #2281, #2378 describe this problem.

This PR is an attempt to make MapStruct use the primary constructor of the data class to instantiate it, and ignore all other generated constructors.

How it works?

Recognizes data classes and the primary constructor by

Note: There might be false positives.

How to review?

TODO

  • Update the reference documentation

Improvement ideas

  • Instead of using the number of componentN() methods, use their exact return types to more accurately determine the primary constructor.

@jawo-a
Instantiate Kotlin data classes using the primary constructor.
e4e7dbb 
Recognizes data classes and the primary constructor by the presence of the annotation `kotlin.Metadata` and `componentN()` methods, although there might be false positives.
@jawo-a jawo-a mentioned this pull request Jul 11, 2022
Closed
1 task
@sskrla
Copy link

sskrla commented Jul 12, 2022

You could also maybe use the generated copy method as a form of detection?

@jawo-a
Copy link
Author

jawo-a commented Jul 13, 2022

@sskrla Yes, I've taken a look at decompiled data classes and the generated copy() method has exactly the same parameters as the primary constructor, although I'm not sure if that is actually guaranteed by Kotlin.

@filiphr
Copy link
Member

filiphr commented Jul 24, 2022

This is an interesting approach @jawo-a. However, I am not sure that I like the taken approach with using the component method count. I would prefer in using the kotlinx-metadata-jvm library as an optional dependency instead. Perhaps with a mapstruct-kotlin-extensions or some other extension that will pull the needed Kotlin dependencies and that will have the needed code to make Kotlin things work properly.

@DavidRomao
Copy link

DavidRomao commented Dec 13, 2022

Hi @filiphr , how would you suggest that mapstruct-kotlin-extensions extension be done ? Would it be okay through the creation of a Constructor Provider SPI, where that extenstion package would then implement ? Otherwise mapstruct would load the current implementation

@jawo-a
Copy link
Author

jawo-a commented Dec 13, 2022

@DavidRomao I've already prepared a change with a Constructor Provider SPI. Going to open a PR in the next few weeks.

@MiguelAngelLV
Copy link

MiguelAngelLV commented Oct 20, 2023

Any change with this?

@filiphr
Copy link
Member

filiphr commented Jan 29, 2026

Closing this in favor of #3978

@filiphr filiphr closed this Jan 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jawo-a @sskrla @filiphr @DavidRomao @MiguelAngelLV