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?

Cirillo

You're just looking at Kotlin/Java interop, what you're missing is Kotlin/JVM runs on the JVM even if your project is 100% Kotlin. And upgrading the Java version brings not just Java language improvements but JVM improvements which may include nice optimizations to things like performance, memory, garbage collector, and bug fixes. – Continuator

@Continuator Running on a JVM 17 will yield these benefits irregardless of the bytecode target of my Kotlin application though, if I'm not mistaken? As far as I know nothing is stopping me from running a Kotlin application with bytecode target 1.8 on a JVM 17. However, the opposite is not true. Thus, the only benefits between the bytecode targets will be through bytecode optimizations made use of by the Kotlin compiler, such as invokedynamic, I assumed. I might be on the wrong here though. – Cirillo

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

Follicle

You're answer did not address the specifics of the Kotlin compiler directly, but gave a thorough overview nonetheless. As there was no better answer in the meantime I'll award the bounty to your answer to not waste the reputation and reward the high quality answer. Thank you. – Cirillo