Why Kotlin needs to bundle its runtime after compiled?

JRE is not only native binary, JRE consist of JVM, java standard library (Java SE API) and other tools like Rmiregisty (Java 8 and lower).

JVM is native application and it directly responsible for executing byte-code. If you write java application that depends only Java SE API, it does't need to add any library to classpath, because Bootstrap classloader and delegate model are doing their job. If you write Kotlin application, kotlinc compiler adds some "runtime code" and your application became to depends from Kotlin library (it seems like your source code does't depends kotlin library, but binary code depends). Because of that, I think, guys from JetBrains call it runtime-library. BTW, according to Central Maven repository, runtime-library was rename to kotlin-stdlib (Kotlin Runtime (deprecated, use kotlin-stdlib artifact instead).

When you write an application in Java, you get to rely on all of the standard class libraries. The java. classes (e.g. java.lang.*, java.util.* ...) are included with every JRE, so you don't need to package them yourself.

Kotlin includes its own standard class library (the Kotlin runtime), separate to the Java class library. To distribute a jar file that can be run by anyone with a plain old JRE, you need to bundle the Kotlin runtime as well.

If you didn't bundle the Kotlin runtime, then your user would have to ensure the Kotlin runtime was on the classpath when executing your application. The page you linked gives an example of this scenario:

Compiling a library

If you’re developing a library to be used by other Kotlin applications, you can produce the .jar file without including the Kotlin runtime into it.

$ kotlinc-jvm hello.kt -d hello.jar

If you're targeting other Kotlin users, then its reasonable to assume they'll already have the Kotlin runtime available to them. However, if you're trying to deploy an application for an end-user, then you want to include the Kotlin runtime so that your application is self-contained.

Greg Kopff's accepted answer explains the general case for needing to bundle something, but I feel that the main point of the question was missed: why should something that compiles to Java byte-code (and is therefore no longer Kotlin) require a Kotlin “runtime”?

My expectation (and that of the questioner, I suspect) is that once compiled, there's no trace of Kotlin anymore, and so there should be no need for a Kotlin runtime.

My expectation is also that a “runtime” is some sort of native binary, like JRE, directly responsible for executing the byte-code.

From the Kotlin language reference on packages, though:

A number of packages are imported into every Kotlin file by default:

• kotlin.*
• kotlin.annotation.*
• kotlin.collections.*
• kotlin.comparisons.* (since 1.1)
• kotlin.io.*
• kotlin.ranges.*
• kotlin.sequences.*
• kotlin.text.*

Therefore, it seems that:

1. the “Kotlin runtime” is actually just a “Kotlin class library” (and not strictly a separate “runtime” like JRE);

2. when Kotlin code is compiled into Java byte-code, the Kotlin is gone, but the byte-code that replaces it needs access to the Kotlin class library; and so

3. the Kotlin runtime must be available to any Java byte-code which was originally Kotlin code, which can be done by bundling the Kotlin runtime with such code.

For me, the Kotlin team's use of the word “runtime” is what triggered so much confusion. I would prefer that they call it “the Kotlin support classes” rather than use a Java term with a very different connotation.

This doesn't explain why so many things under the kotlin package namespace are needed, or whether Kotlin files can be written that don't actually rely on the Kotlin runtime at all, but perhaps these are issues for another question.

Kotlin runtime is nothing but a set of libraries ( bundled in a jar) which is referred during runtime, just like any other jar in classpath.