[Internal] Add issue label for Kotlin

[Marcono1234]

There are multiple issues which are exclusively about using Gson with Kotlin. It might be useful to have a "kotlin" label which we can use on these issues so that we can more easily search and group them in the future.

Most or all of these issues are about Gson not supporting Kotlin-specific language features at the moment.

If an issue is also reproducible with Java but possibly someone mentioned that Kotlin is affected as well, then it should probably not be labelled "kotlin".

[Marcono1234]

Maybe a "java-8" label would be useful as well, for all issues which require Java 8 as minimum version.

That could be for example the issues about built-in support for java.time, but also the issue about being able to build with JDK 21 (without any custom configuration accounting for Java 7 being unsupported).

[eamonnmcmanus]

I've created the kotlin label and applied it to a few open issues. I'm a bit less sure about java-8. Maybe we should just drop support for earlier Java versions at this point. Java 8 is already nearly 10 years old, and I believe issues with Android are generally solved with desugaring.

[Marcono1234]

Thanks! That were actually less open Kotlin-related issues than I had expected. It seems many of the closed issues are just duplicates. I have also added the label to pull request #1844 since that seems to be explicitly about Kotlin, and adds little or no value for Java users.

Maybe we should just drop support for earlier Java versions at this point.

Yes I think that would be ideal. I just wasn't sure how soon we will get to that. For now here is a (possibly incomplete) list of Java 8 related issues:

• Could you please add support of java.time as is part of Java8 ? #739 / GSON Serialization/Deserialization of Java 8 Date API #1059
• Support for java.util.Optional #1102
• Build failure with Java 21 #2501
  (we can remove the special casing for JDK 21 and properly support it for building)
• Add JsonDeserializationContext.deserialize overload with TypeToken parameter #2216
  (allows implementing this with a default method)

But there is probably indeed no need for a label then.

[eamonnmcmanus]

That's fair. I've created java8 which we can use to track followup work once we drop support for earlier versions. I've added it to the issues you mentioned.

[Marcono1234]

@eamonnmcmanus, do you think a "proguard-r8" label or similar for all ProGuard and/or R8 related issues and pull requests would be useful?

Technically ProGuard and R8 behave differently, and for ProGuard it might also depend on which plugin you are using (Guardsquare/proguard#337), and for R8 whether you are using "compatibility mode" or "full mode", but it is probably not worth having separate labels for that, but instead just one covering any obfuscation and shrinking tool.

[eamonnmcmanus]

Sure, yes, let's have proguard-r8.