The Kotlin kernel turns a notebook cell into a compiled Kotlin program

It is a bridge, and the compiler is the point

The description of the project is precise: the kernel lets you write and run Kotlin code inside a Jupyter Notebook environment, and it essentially acts as a bridge between Jupyter Notebook and the Kotlin compiler. That is a different thing from a scripting interpreter for Kotlin, and the difference shows up in what the feature list promises. Alongside running code cells and seeing outputs immediately, you get basic code completion and error analysis, which are compiler features rather than interpreter features. The list of benefits is written in user terms: accessing APIs within cells and using APIs for handling outputs, retrieving information from previously executed code snippets for quick project exploration, and importing various libraries with a single line of code or integrating new libraries into your project. The kernel enhances what the Kotlin REPL already gives you in IntelliJ IDEA, with the notebook as the delivery mechanism.

Where it runs, and what the floor is

The support section is a set of hard numbers rather than a compatibility promise. The kernel uses the Kotlin compiler of version 2.4.0-dev-6891, so it tracks a development build of the compiler rather than pinning a stable one. The client table gives the minimum supported versions: JupyterLab 1.2.6, Jupyter Notebook 6.0.3 and Jupyter Console 6.1.0. The operating systems it was tested on are Windows, Ubuntu Linux and macOS. The component is explicitly marked as in Beta, and the badge in the README header says so too. The pieces are distributed in several places: a PyPI package named kotlin-jupyter-kernel, an Anaconda package, a Gradle plugin for the API, and Maven Central artifacts under the org.jetbrains.kotlinx group, and the project is a JetBrains official project under the Kotlin organisation with an Apache 2.0 licence.

Three clients, three ways in

The kernel is usable from three directions and the documentation covers each. The Kotlin Notebook in IntelliJ IDEA is fully integrated with the kernel, and it is the path with the least friction because the plugin and the kernel versions are managed together. Datalore is the hosted JetBrains environment, where the kernel is already available. And plain Jupyter Notebook and JupyterLab need the kernel installed into your environment. The repository carries a set of sample notebooks covering communication, DeepLearning4j with and without CUDA, Gral, KotlinNumpy, Krangl, LetsPlot, resources, Swing examples, the Titanic dataset, outputs, an API guide and screenshots, and the samples are runnable online through Binder. So before installing anything you can see what the kernel actually does in a browser tab.

Dependency resolution happens inside the cell

The dependency resolving section is the part that makes the kernel feel like a real development environment rather than a REPL in a browser. There are annotations for it, a Gradle-like syntax for it, and a section on handling dependencies, plus a list of the default repositories the kernel resolves against. The practical effect is that a notebook can pull in a library and use it in the same cell, and the state of the session carries the dependency forward, which is what makes the notebook usable for exploration of a new library rather than only for plotting data you already have. The list of supported libraries is given separately, which is a fair signal about what the ecosystem around the kernel actually covers.

REPL commands, line magics and rich output

The feature list includes a section on REPL commands, which is the mechanism for the things a notebook cannot express as Kotlin. There is a section on line magics, the percent-prefixed shortcuts that Jupyter users know, and then the output side. Rich output covers rendering, with a subsection on the common rendering semantics, and the mechanism is the REPL commands again, since the kernel has to translate a request for a particular display into the right artefact. Rendering is where a notebook kernel either works or does not, because a value that is a data frame or a plot has to come back as something Jupyter can display, and the common rendering semantics page is the reference for what the kernel emits.

The repository is a Gradle build with a lot of surface

The top level of the repository shows a project with many parts. There is a `jupyter-lib/` directory for the Jupyter side, a `build-plugin/` for the Gradle plugin, `distrib/` and `distrib-util/` for packaging, `src/` for the kernel itself, `api-examples/` for the API, `samples/` for the notebooks, `binder/` for the online environment, `resources/` and `docs/` for the rest, and a `teamcity/` directory for the build server. The build is Gradle with Kotlin DSL, with a `settings.gradle.kts` and a `build.gradle.kts`, plus a `gradle.properties` and a `gradle.properties.local` for local overrides. There is an `.idea/` directory for the IDE configuration and a `.run/` directory for run configurations. The last push to the master branch was on 2026-07-23, and the repository has no GitHub releases, so the versions that matter are the ones published to PyPI, Conda and Maven Central.

Editorial conclusion

Adopt the Kotlin kernel if your team works in Kotlin and wants notebook-style exploration without leaving the language, since the kernel gives you a real compiler behind the cells rather than an interpreter approximation. Do not adopt it for a stable production pipeline, because the project states the component is in Beta and pins a development build of the Kotlin compiler. Verify first which client versions you run, since JupyterLab 1.2.6, Jupyter Notebook 6.0.3 and Jupyter Console 6.1.0 are the documented minimums, and decide whether you want the pip or the Conda distribution before you start.

Frequently asked questions

Official sources

1. Issues
2. Kotlin/kotlin-jupyter on GitHub
3. License: Apache-2.0
4. README