Benefit of specifying -jvm-target / jvmTarget version other than 1.8

Question

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:

• on JVM 9+ targets, string concatenations are compiled into dynamic invocations (invokedynamic), see release blog of Kotlin 1.5.20
• on JVM 10+ targets, Java's 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?

Answer 1

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