Skip to content
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

Repository methods are not overriden properly in Kotlin [DATACMNS-1265] #1703

Closed
spring-projects-issues opened this issue Feb 27, 2018 · 6 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Aleksandr opened DATACMNS-1265 and commented

For java findById method we can write to methods in kotlin:

override fun findById(id: Long?): Optional<User>

override fun findById(id: Long): Optional<User>

The first one with nullable parameters is invoked by data-rest. If we add annotations to it e.g. @PreAuthorize it works as expected. But with -Xjsr305=strict compiler argument that is added by spring Initialzr the second one is the only possible override, though it doesn't work the right way, cause it's not invoked through data-rest.

Project to reproduce described behavior is linked to the issue


Reference URL: https://gitlab.com/AleksandrSl/spring-sandbox/tree/data-rest-security-RC2

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Mark Paluch commented

That's some weird Kotlin compiler behavior.

fun findById(id: Long?): Optional<User>

compiles to

Optional<User> findById(@Nullable Long paramLong);

which is the correct override as repositories are typed with reference types and not primitives. Enabling JSR305 strict mode seems to require non-null primitive types

fun findById(id: Long): Optional<User>

compiling to

Optional<User> findById(long paramLong);

which is not an override of findById(ID) because ID is java.lang.Long and not long. Therefore, Spring Data does not consider this method.

You can leave out the override keyword to generate the proper method signature for now. I'll do further investigation what else we could do here.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Mark Paluch commented

I filed a bug report in the Kotlin issue tracker

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Aleksandr commented

Thanks, I tried using without override, but switch off JSR305 seems prettier for the moment.
By the way it's the defined behavior of Kotlin compiler, types are compiled to primitives where possible.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Mark Paluch commented

It seems that Spring's org.springframework.lang.NonNullApi lets the compiler treat all parameters as non-nullable without regard to the actual type. Attempting to override the method fails in any case. From this standpoint, it's a Kotlin compiler bug as the actual underlying type isn't considered in the override

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 27, 2018

Aleksandr commented

Compiler doesn't look at ```java
org.springframework.lang.NonNullApi




@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 2, 2018

Mark Paluch commented

This issue is going to be addressed by the Kotlin team, so closing this ticket for the time being

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants