Skip to content

Support for Kotlin inline value classes #1186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dgerhardt opened this issue Apr 10, 2025 · 5 comments
Open

Support for Kotlin inline value classes #1186

dgerhardt opened this issue Apr 10, 2025 · 5 comments
Assignees
Labels
in: data Issues related to working with data status: on-hold We can't start working on this issue yet

Comments

@dgerhardt
Copy link

Currently, Spring for GraphQL does not work with Kotlin inline value classes. When these are used as field types, I have noticed two issues:

  1. Schema mappings do no longer work out of the box. The cause is probably that the Kotlin compiler mangles method names to avoid conflicts (https://kotlinlang.org/docs/inline-classes.html#mangling). This can be worked around by using @JvmName or explicit names with @SchemaMapping.
  2. Spring for GraphQL is no longer able to use constructor binding for classes with value class fields. This seems to be caused by DefaultConstructorMarker which the Kotlin compiler adds to the constructor's signature. I have not found any workaround for this to make this work with Spring for GraphQL.

Spring Data already already supports value classes since version 3.2. It would be great if Spring for GraphQL would support them too, so they can be used throughout the whole Spring stack.

Related Spring Data PR: spring-projects/spring-data-commons#2866
Related Spring Data docs: https://docs.spring.io/spring-data/commons/reference/object-mapping.html#mapping.kotlin.value.classes

Exception when constructor binding with a value class:

java.lang.IllegalStateException: Invalid number of parameter names: 8 for constructor public com.example.Entity(java.util.UUID,[...],kotlin.jvm.internal.DefaultConstructorMarker)
        at org.springframework.util.Assert.state(Assert.java:101) ~[spring-core-6.2.5.jar:6.2.5]
        at org.springframework.beans.BeanUtils.getParameterNames(BeanUtils.java:672) ~[spring-beans-6.2.5.jar:6.2.5]
        at org.springframework.graphql.data.GraphQlArgumentBinder.bindMapToObjectViaConstructor(GraphQlArgumentBinder.java:295) ~[spring-graphql-1.3.4.jar:1.3.4]
        at org.springframework.graphql.data.GraphQlArgumentBinder.bindMap(GraphQlArgumentBinder.java:261) ~[spring-graphql-1.3.4.jar:1.3.4]
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 10, 2025
@bclozel
Copy link
Member

bclozel commented Apr 10, 2025

Can you explain the difference with #1163 please?

@dgerhardt
Copy link
Author

dgerhardt commented Apr 10, 2025

@bclozel I don't think the issues are related. While both are related to constructors and Kotlin, this issue is about the use of value classes while the existing issue is about using a constructor for only some properties and setters for others. A fix for #1163 might provide a workaround for value classes but I'm not entirely sure.

@bclozel bclozel self-assigned this Apr 10, 2025
@bclozel
Copy link
Member

bclozel commented Apr 15, 2025

Rather than pointing to other PRs, can you share a code snippet or a minimal reproducer?
It seems Spring Framework does support inline/value classes in BeanUtils and we are using just that method to find the constructor. I guess we're missing something else in the binding process but I'm not sure what.

@bclozel
Copy link
Member

bclozel commented Apr 15, 2025

I've narrowed this down to a problem in Spring Framework. I've opened spring-projects/spring-framework#34760

There are many subtle issues with Kotlin<->Java reflection and I'm not sure this use case will be supported in Spring for GraphQL 1.x. We might wait for broader support in Spring Framework 7.0 with spring-projects/spring-framework#33630

@bclozel bclozel added in: data Issues related to working with data status: on-hold We can't start working on this issue yet and removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Apr 15, 2025
@dgerhardt
Copy link
Author

Thanks for looking into this so quickly. I'm looking forward to broader support in Spring Framework 7.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues related to working with data status: on-hold We can't start working on this issue yet
Projects
None yet
Development

No branches or pull requests

3 participants