As I was looking into migrating from `values()` to...

# apollo-kotlin

[Stylianos Gakis]

As I was looking into migrating from values() to entries for all enums in our project as I bumped to Kotlin 1.9, I noticed that the generated files from apollo-kotlin are using it quite extensively. Would it benefit the generated code if it started generating entries instead of values()? Reading the KEEP makes me feel like they’re always the better choice to make going forward. Are there concerns about backwards compat or something like that?

[mbonnin]

I was reading about that this morning as well! 100% we should move to that.

[mbonnin]

We still want to support Kotlin < 1.9 so it'd have to be a config option or detect from KGP like we did when introducing sealed classes

[mbonnin]

Want to open an issue so we can keep track of this?

[Stylianos Gakis]

Of course! https://github.com/apollographql/apollo-kotlin/issues/5171

[Yang]

We still want to support Kotlin < 1.9 so it'd have to be a config option or detect from KGP like we did when introducing sealed classes

I’m naive but can we not figure out the Kotlin version in the current project? 😄

[mbonnin]

Yea, there are a lot of Kotlin versions 😄 . The compiler that's used to compile the apollo- libs is 1.9 (source)

[mbonnin]

But we claim compatibility with 1.6 IIRC through apiVersion and languageVersion

[Yang]

Is it possible to figure out the current kgp version when running the build?

[mbonnin]

You can modify your build scripts to println kotlinPluginVersion

[mbonnin]

(AFK right now but I think it's the name of the extension)

[mbonnin]

Or maybe .gradlew -i outputs something

[ephemient]

./gradlew buildEnvironment will say, if it's loaded from plugin (it won't if it's loaded from parent classpath though)

[Yang]

I was more thinking from a plugin’s perspective, is it viable to make this kind of decisions based on the consumer’s kotlin version?

[ephemient]

it shouldn't be based on the consumer's kotlin version though, it should be based on their target language/api level. which makes it trickier

[mbonnin]

Right, language/api level is best 👍 I'm guessing it's a language feature more than an API one? but not sure...

[ephemient]

I feel like it's both, but I wrote out

-language-version
             1.8     1.9     2.0
-api-version
     1.8      no     ???     ???
     1.9      no     yes     ???
     2.0      no     yes     yes

and I'm still not sure…

[bod]

from my tests it's:

-language-version
             1.8     1.9     2.0
-api-version
     1.7      no     no      no
     1.8      no     yes     yes
     1.9      no     yes     yes
     2.0      no     yes     yes

So language-version >= 1.9 && api-version >= 1.8

[mbonnin]

Interesting! I'm curious what's the error with language-version = 1.9 && api-version = 1.7 , what API is missing?

[bod]

e: Main.kt:3:18  The feature "enum entries" is only available since API version 1.8

[mbonnin]

AH well, fair enough, the compiler doesn't want us to see the gory details

[bod]

I guess kotlin.enums.EnumEntries<E> doesn't exist prior to 1.8

[mbonnin]

Makes sense 👍