Convert to Kotlin

[KotlinIsland]

It would be good if this library was converted to Kotlin such that it could be used with Kotlin/common, Kotlin/JS and Kotlin/native.

I wouldn't mind doing this.

[chashnikov]

It still makes sense to have this library compiled from Java sources to ensure that its class-files doesn't include unnecessary meta-information from Kotlin. So if you want to have a similar set of annotations for non-JVM Kotlin projects it would be better to create a new library. Also note that the most commonly used annotations from this library (@NotNull and @Nullable) don't make sense for Kotlin since it supports nullability in its type system, so they shouldn't be included into Kotlin variant of the library.

[KotlinIsland]

Ok, thanks.

I plan on making this, and points I should consider?

[elizarov]

To achieve this, you can create a module with common Kotlin code that has the corresponding expect annotation class Xxx(...) declarations in the same package as the JetBrains Java versions are in. You also create Kotlin/JS and Kotlni/Native modules that have the corresponding actual annotation class Xxx(...) declarations. The Java code will automatically match those declarations and can be compiled by javac as before. The Kotlin/Common, Kotlin/JS, and Kotlin/Native modules compilations will produce new artifacts that can be used in multiplatform Kotlin projects.

[KotlinIsland]

@elizarov @chashnikov Kotlin MPP requires Gradle >= 6, Gradle 6 doesn't support java 5, this project targets java 5.

Could java 5 support be dropped? or is there another option that could be chosen?

[chashnikov]

@KotlinIsland as far as I know Kotlin compiler cannot produce bytecode for Java 5 anyway, so it doesn't make sense to support Java 5 in a library for Kotlin.

[KotlinIsland]

@chashnikov The implementation I was thinking of would make the java 8 target a Kotlin MPP project and leave the java 5 as is.

[aSemy]

To achieve this, you can create a module with common Kotlin code that has the corresponding expect annotation class Xxx(...) declarations in the same package as the JetBrains Java versions are in. You also create Kotlin/JS and Kotlni/Native modules that have the corresponding actual annotation class Xxx(...) declarations. The Java code will automatically match those declarations and can be compiled by javac as before. The Kotlin/Common, Kotlin/JS, and Kotlin/Native modules compilations will produce new artifacts that can be used in multiplatform Kotlin projects.

@elizarov Hi, I've tried this workaround for the @Language annotation in Kotest, but it causes clashes with the actual @Language implementation, and errors on Android

kotest/kotest#3387

Perhaps I made a mistake in the implementation: kotest/kotest#3328

If it's not possible, then could the @Language could be converted to Kotlin? It would also help with other issues https://youtrack.jetbrains.com/issue/KTIJ-12951/

UPDATE: Ah I realise the mistake I made, I think I fixed it.

1. change expect annotation class Language to expect annotation class KotestLanguage

2. in non-JVM platforms, copy-paste the JVM @org.intellij.lang.annotations.Language implementation

3. then in all platforms, use

   actual typealias KotestLanguage = org.intellij.lang.annotations.Language

   Which in non-JVM targets will use the copy-pasted annotation, and in JVM targets the IntelliJ annotation.

However, this is a little verbose and repetitive. It would be nicer if @Language was multiplatform.

[DRSchlaubi]

You can use comments to inject the language, however, having a KMP version of this would be great either way. It would also be great to finally support the @mutable and @immutable annotations in Kotlin itself

[aSemy]

You can use comments to inject the language, however, having a KMP version of this would be great either way. It would also be great to finally support the @Mutable and @Immutable annotations in Kotlin itself

I agree, plus I'll add that KMP annotations are also necessary when someone wants to publish a library with the annotations, since the comment-injections only work for local source code, and aren't available in published code.

[aSemy]

@chashnikov I think there are some strong cases for providing KMP annotations - would you consider reopening this issue?

[DRSchlaubi]

It wouldn't even be required to port the whole library to Kotlin, they could use expect/actual declarations like Roman suggested