I’m trying to use the runtime jar from http://central.maven.org/maven2/org/jetbrains/kotlin/kotlin-runtime/1.0.3/ with the 1.0.3 CLI kotlinc ( Release 1.0.3 · JetBrains/kotlin · GitHub )
but the compiler chokes on every reference reference to something from the library.
I’ve made sure that the jars are in the classpath 
The specific command I’m using:
kotlinc -no-stdlib -cp "out;lib/kotlin-reflect.jar;lib/kotlin-runtime.jar" src
It’s also strange that the MD5 of the jars from (1) Maven Central, (2) the 1.0.3 github release and (3) supplied by IntelliJ are all different.
Using the jars from (2) and (3) leads to a successful compilation.
As an additional meta-question: what is the point of actually doing what I’m doing, i.e. pulling separate kotlin-runtime.jar and kotlin-reflect.jar and specifying no-stdlib. I’ve been doing it because it’s what IntelliJ does as well. Is the reason that newer compilers can handle older runtimes? What are the guarantees exactly?
Looks like you are missing kotlin-stdlib, which is not the same as kotlin-runtime.
You seem to be right, adding http://central.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/1.0.3/ fixes it.
Follow-up questions:
-
What is the distinction between kotlin-stdlib.jar and kotlin-runtime.jar ?
-
Why does it work if I copy kotlin-reflect.jar and kotlin-runtime.jar from the kotlinc install directory (so that no kotlin-stdlib.jar are present) ?
-
The question from the end of my original post:
Okay, so answering some of my own questions:
-
From cursory inspection with jar tf, it seems that kotlin-runtime.jar contains, as one would suspect, the runtime support (so everything that is needed for translating linguistic constructs: iterators, function0, etc). kotlin-stdlib.jar is the “rest” of the standard library (stuff that you can leave out, unlike the runtime part, you need to name it to use it).
-
It seems that lib/kotlin-runtime.jar from the installation directory combines the maven kotlin-runtime.jar and kotlin-stdlib.jar (and maybe some other stuff?).
Question (3) remains.
kotlin-reflect is only necessary if you want to use Kotlin reflection. It’s currently much bigger than the other Jars, and many apps/libs won’t need it.
The point of -no-stdlib is to decouple compiler and stdlib versions. There is really no good reason to couple them, except to make direct use of the compiler CLI more convenient. (But then most users should use a build tool with Kotlin support instead of the compiler CLI.) As for compatibility guarantees, I’d check prior posts by the Kotlin team on this topic.
Mmh okay.
So I guess the reason is the ability to make breaking change to the library while keeping the language backwards compatible (otherwise, if you must already adapt your code to breaking language changes, you might as well adapt it to library changes).
Still, it’d help if all of this wasn’t so very much confusing (like kotlin-runtime.jar being two different things depending on source). And it’s not like it’s some expert stuff either, it’s right there in your face when you want to use kotlin.