As of Kotlin 1.6.0, for Kotlin/JVM projects one may specify the -jvm-target version option up to Java 17, see general and Gradle plugin documentation.
What are the benefits of doing so?
I couldn't find much on the benefits of specifying something other than the default value of 1.8.
The only things I could find on this were:
Records are supported, see release blog of Kotlin 1.5.0.Both seem negligible to me.
Especially because when specifying a higher target, one looses the ability to use the resulting artifact in projects stuck with Java 1.8, which seems undersireable especially for libraries.
Is there something I missed here?
I don’t know what Kotlin actively uses or supports.
The following features available in later Java environments may provide a benefit to other programming languages, even if you are not actively using them in your application code:
Concurrent constructs of your language may use VarHandle internally even if you don’t use this API directly. [JDK 9]
If your language needs it, reachabilityFence allows to prevent garbage collection prior a point of execution, instead of relying on fragile or expensive work-arounds [JDK 9]
An official way to add classes to the current environment dynamically, rather than hacking into JRE internals [JDK 9]
You already mentioned string concatenation… [JDK 9]
When you create a module declaring the required dependencies, you can create a customized JDK containing only the required modules, to be deployed with the application (which eliminates the need for 1.8 compatibility anyway). [JDK 9]
Classes belonging to a nest can access each others private members without the need for helper methods. The compiler of your language can decide which classes belong to a nest, it doesn’t have to be the semantic of Java’s nested classes. [JDK 11]
Custom dynamic constants. You can have arbitrary constants loadable by an ldc instruction, which is constructed by a bootstrap method on the first execution and subsequently reused. This means the language can use its own constants of its own types the same way as Java’s built-in constants (think, string interning). [JDK 11]
Create dynamic anonymous classes using an official API instead of assuming the presence of the proprietary sun.misc.Unsafe [JDK 15]
Sealed classes are directly supported by the JVM, so if the language has such a concept, it can translate it directly instead of emulating it. [JDK 17]
Perhaps something more that is useful for the particular language implementation but not obvious to us, not trying to implement the language on the JVM