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

@Consistency annotation results in Kotlin compilation error [DATACASS-797] #964

Closed
spring-projects-issues opened this issue Aug 31, 2020 · 6 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Aug 31, 2020

Gautam Jolly opened DATACASS-797 and commented

Compilation of a Kotlin function, that is annotated with @Consistency, results in compilation error "An annotation argument must be a compile-time constant". Note that fhis feature worked well in spring-data-cassandra-2.1.X.

@Consistency(DefaultConsistencyLevel.QUORUM)
fun doSomething()

The equivalent Java code works just fine:

@Consistency(DefaultConsistencyLevel.QUORUM)
public void doSomething();

Affects: 3.0.3 (Neumann SR3)

Attachments:

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2020

Gautam Jolly commented

Uploaded demo-java-kotlin.zip comprising of:

  1. Project "demo-java", File "DemoJava.java", Compiles successfully.
  2. Project "demo-kotlin", File "DemoKotlin.kt", Does not compile.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2020

Mark Paluch commented

We're referring to an enum type in @Consistency which is listed as an allowed annotation constructor type (see https://kotlinlang.org/docs/reference/annotations.html#constructors). I'm not sure we can do here anything

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2020

Gautam Jolly commented

Some options:

  1. I suppose there is a good reason for the way the DefaultConsistencyLevel enum is structured, i.e. implementing an interface, that in turn has references back to the enum, and having name collisions between interface fields and enum values. If you've an open channel with the Kotlin team, then check with them if they'd be willing to support this usecase.
  2. Make @Consistency annotation's value attribute optional. Add another int/String/??? attribute that maps to a DefaultConsistencyLevel.
  3. Add a note to the reference document stating that this feature is not compatible with Kotlin

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2020

Mark Paluch commented

I assume that the enum design along with the interface constants creates some sort of conflict on the Kotlin side. Can you file a bug report at https://youtrack.jetbrains.com/issues/KT?

The current arrangement isn't ideal as we're referring to a driver class that is internal. We don't want to keep our own ConsistencyLevel copy nor perform a string lookup as these approaches create further issues like inconsistencies. We also cannot refer to the ConsistencyLevel interface as annotation values need to be constant.

Paging Alexandre Dutra, maybe there's something that can be done on the driver side to improve here

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 3, 2020

Gautam Jolly commented

To workaround this issue:

  1. We created an annotation, which is meta-annotated with \@Consistency, in Java
@Documented
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Consistency(DefaultConsistencyLevel.QUORUM)
public @interface QuorumConsistency {}
  1. Applied the newly created annotation to the Kotlin function
@QuorumConsistency //@Consistency(DefaultConsistencyLevel.QUORUM)
fun doSomething()

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 23, 2020

Mark Paluch commented

According to the Cassandra driver team, they intend to address the issue on their side. Closing this ticket until further notice

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