Kotlin: What the JetBrains Repository Actually Contains

What the Kotlin repository is, and who it is for

The repository describes itself as the Kotlin Programming Language, developed by JetBrains and contributors, with the language site at kotlinlang.org. The practical content is the implementation: top-level directories include compiler, core, libraries, kotlin-native, js, wasm, plugins, and tests. That tells you who the repository is for. It is for people who build the toolchain, add a compiler feature, fix a standard library bug, or produce the Gradle and Maven plugins. It is not the place to learn the syntax. The README points beginners at the Getting Started Guide and at try.kotlinlang.org, which is a browser playground, and it points plugin users at the IntelliJ IDEA plugin, the Eclipse plugin, and a Sublime Text package. If your goal is to write an Android app or a backend service, cloning this repository is the wrong first move. The README's own framing is a compiler codebase, and its build instructions assume you are comfortable with Gradle and with large dependency graphs.

How the compiler, plugins and standard library are laid out

The README names two heavyweight dependencies that appear on first configuration: intellij-core, described as part of the command line compiler and containing only necessary APIs, and idea-full, a full IntelliJ IDEA Community Edition used by the plugin module. That split is the clearest architectural signal in the repository. The command line compiler does not need the whole IDE; the IntelliJ plugin does, and it pulls the IDE in as a build dependency. Around that core sit the artifacts the README lists as public: the standard library, reflect, and kotlin-test, all exercised together by the coreLibsTest task, plus a Gradle plugin and a Maven plugin. Kotlin/Native is built separately and documented in kotlin-native/README.md, and the README notes that some artifacts, mainly the Maven plugin ones, are built with Maven rather than Gradle, referring to libraries/ReadMe.md. So there is no single build path. Gradle is the default, Maven covers a subset, and Kotlin/Native has its own instructions. Multiplatform support is presented as a headline capability: sharing business logic and UI between Android, iOS, desktop and web, with links to share code on all platforms or only on similar platforms.

Building Kotlin from source: install and first run

The README states the project is built with Gradle. On Unix or macOS you run the wrapper, and on Windows you run the batch file. The wrapper is present at the repository root as gradlew and gradlew.bat, so no separate Gradle installation is required.

./gradlew <tasks-and-options>

On Windows the equivalent is gradlew <tasks-and-options>. The first configuration downloads intellij-core and idea-full. The README warns these are quite large and that you may face timeouts depending on your connection, and it gives the flags to raise the limits.

./gradlew -Dhttp.socketTimeout=60000 -Dhttp.connectionTimeout=60000

The repository uses Gradle toolchains to select and provision the required JDKs from Eclipse Adoptium. If you prefer to supply JDKs yourself, the README says you can do so through environment variables, with the supported names listed in gradle.properties, and that you can disable toolchain auto-detection with this option.

-Porg.gradle.java.installations.auto-detect=false

On Windows the README also asks you to enable long paths in the repository before building.

git config core.longpaths true

For a usable compiler distribution, the README lists the dist task, which assembles into the dist/kotlinc/ folder. After that build you should find the distribution in that directory. Other tasks named in the README are clean, install (which builds and installs public artifacts into the local Maven repository), coreLibsTest, gradlePluginTest, and compilerTest. Note the README's statement that local builds do not run ProGuard and have jar compression disabled by default, and that -Pteamcity=true reproduces the TeamCity build.

Dependency verification will stop your first build

The README is explicit that dependency verification is enabled for all Gradle builds in the repository. Gradle checks md5 and sha256 hashes of used dependencies against gradle/verification-metadata.xml and fails with a Dependency verification failed error when local artifacts are absent or their hashes differ from the listed ones. For a contributor this is a real friction point: adding or updating a dependency means updating verification-metadata.xml in the same commit, and the README says that file should only be updated by commits that modify the build. For someone who just wants a compiler build, it means your first run can fail before it ever compiles anything, and the fix is not a flag you invent but the documented hash metadata. This is a deliberate supply chain trade-off, and it is worth knowing before you start rather than after.

Where Kotlin is the wrong tool

Kotlin's pitch is one language across JVM, Android, JavaScript, Wasm and native targets, and the repository layout backs that up with js, wasm and kotlin-native directories alongside compiler and libraries. The cost is a build system that is itself a large software project. The README's build environment section is the evidence: toolchain provisioning, environment variable overrides, long path configuration on Windows, multi-gigabyte IDE dependencies, and hash verification. If you need a compiler you can build in a few minutes on a laptop with a poor connection, this is not it. If you need a language runtime with no JVM or IDE lineage at all, the IntelliJ dependencies are dead weight you cannot remove from the plugin module. And if your target platform has no Kotlin support documented in the supported platforms list, the multiplatform story does not apply to you. The README does not document any rollback procedure for a failed build, and it does not describe supported downgrade paths between compiler versions, so treat version choice as something to settle before you start.

Kotlin against Java, and against writing plain JVM code

The most common comparison is Kotlin against Java, and the repository itself shows the difference in kind rather than in benchmarks. Kotlin compiles to JVM bytecode and interoperates with Java, so the decision is not a runtime migration but a source-level one. What Kotlin adds at the language level is visible in the repository's own artifact list: a standard library with its own tests, kotlin-test as a first-class testing artifact, coroutines as a documented topic, and multiplatform targets that Java does not have. What Java keeps is a smaller toolchain surface: no separate compiler repository to build, no idea-full dependency for IDE support, no dependency verification metadata to maintain. The honest framing is that Kotlin buys conciseness and shared code across platforms and pays for it with a more complex build and a compiler that moves on its own release cadence. The repository shows that cadence plainly: releases v2.4.20-RC2, v2.4.20-RC3 and v2.4.20 appeared within about two weeks of each other in August and September 2026, with the last push to master on 2026-09-10.

Licence, maintenance and upgrade cost

The README carries an Apache License 2.0 badge linking to apache.org, and the repository has a license/ directory. The repository metadata itself lists the licence as unknown, so if the licence terms matter to your organisation, read the files under license/ rather than the badge. Maintenance is visible in the release history: v2.4.20 was published on 2026-09-07, with two release candidates in the preceding weeks, and the last push to master was on 2026-09-10. That is a short interval between release candidates and the final release, which is normal for this project and also means you should expect to move versions more often than you might with a more conservative platform. Upgrade cost is not documented in the README; there is no migration guide or rollback section there. The ChangeLog.md file at the repository root is where release-level changes are recorded, and that is the file to read before bumping a compiler version in a build. This is not legal advice: Apache 2.0 is a permissive licence with patent terms, but the badge is not a substitute for the licence text.

Editorial conclusion

Adopt Kotlin if you are writing JVM, Android, JavaScript, Wasm or native code and want one language with a shared standard library; the repository's own build is for people who need to modify the compiler, not for ordinary application work. Do not clone it expecting a quick start: the README warns that intellij-core and idea-full are large downloads and that timeouts are likely on a slow connection. If you only want to write Kotlin, use the Getting Started Guide or try.kotlinlang.org instead. Before building from source, verify the JDK toolchain setup in gradle.properties, the long-path setting on Windows, and whether dependency verification against gradle/verification-metadata.xml will block your first build.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/kotlin on GitHub
3. Project website
4. README
5. Releases