What Scala 3 is and where it runs in 2026

Scala 3 is a statically typed language that combines object-oriented and functional programming, and its main home is the Java Virtual Machine. When Scala 3.9.0 compiled the small program on this page, it wrote five files: three .class files that any JDK 17 or newer can run, and two .tasty files that keep Scala’s own view of the types. The same language also compiles to JavaScript and to native programs.

Scala ships on two release lines, and every version this track mentions, from 3.3 to 3.10, belongs to one of them. This lesson shows where Scala code runs, how to choose a version for an application or for a library, and how to read the versions behind each recorded run in this track.

Scala compiles to class files that any JDK 17 or newer runs

Here is a whole Scala 3 program. @main marks the method that starts it, and the method prints the version of the Scala library that runs it:

// A whole Scala 3 program: @main makes the method hello the program's starting point.
@main def hello(): Unit =
  val version = scala.util.Properties.versionNumberString
  println(s"Hello from Scala $version")

The session below compiles it into a folder named classes, lists what the compiler wrote, and looks inside with javap, a tool that comes with every JDKJDK: The Java Development Kit: a JVM together with the Java compiler and tools such as javap. Scala 3.8 and later need JDK 17 or newer to compile and run. More in “Install Scala 3.9, a JDK and an editor”. Each session in this track shows the commands after $ and what they printed. They run with --server=false, which starts a fresh compiler for each command instead of using a background compile server (the third lesson explains the difference), and on JDK 25 they leave out a few WARNING lines that the scala launcher prints about itself, which the next lesson shows and explains.

from session import run

# Compile hello.scala into the folder classes, list what the compiler wrote, then look inside with the JDK's javap.
run("""
cd hello
scala compile . --server=false -d classes
ls classes
javap -cp classes hello
javap -v -cp classes hello | grep "major version"
""")

$ cd hello
$ scala compile . --server=false -d classes
$ ls classes
hello.class
hello.tasty
hello$package.class
hello$package.tasty
hello$package$.class
$ javap -cp classes hello
Compiled from "hello.scala"
public final class hello {
  public hello();
  public static void main(java.lang.String[]);
}
$ javap -v -cp classes hello | grep "major version"
  major version: 61

The compiler wrote five files. The three .class files hold bytecodebytecode: The instructions in a .class file. They are written for the JVM rather than for a real processor, so one compiled file runs on Windows, macOS and Linux alike., the instruction set of the JVMJVM: The Java Virtual Machine: the program that loads compiled class files and runs their bytecode on your computer's processor. Scala's main platform; every JDK includes one.: hello.class is the program’s starting point, and the two hello$package classes hold the file’s top-level definitions. javap shows that hello is an ordinary JVM class with the public static void main(java.lang.String[]) method that every Java program starts from, generated from the @main method. So a Scala program can call any Java library, and Java code can call Scala classes, because both end up as the same kind of class file.

The line major version: 61 is the class-file version of Java SE 17 in the JVM specification. A JVM runs class files up to its own version, so JDK 17, 21 and 25 all run this program, and an older JDK refuses it. That is why Scala 3.8 and later need JDK 17 or newer, to compile and to run.

The two .tasty files hold TASTyTASTy: The typed syntax trees that the Scala 3 compiler writes into .tasty files beside the .class files. Later compilers and tools read them to see the full Scala types of compiled code., the typed trees the compiler built while it checked the program. Bytecode loses part of the types: a List[Int] becomes a list of plain objects, and the JVM has no idea of a union type such as Int | String. TASTy keeps them all, so when another Scala project uses this code as a library, its compiler, and editors such as Metals, read the full Scala types from these files. Step through the same compile and watch which program reads which file:

The same code can also become JavaScript or a native program

The JVM is the main platform and the one this track uses, but two other projects compile the same language for other places. Scala.js turns Scala into JavaScript for browsers and Node.js, and Scala Native compiles it ahead of time, through LLVM, into a program that the operating system runs directly, with its own small runtime and no JVM:

On the JVM, Scala code can use every Java library. Apache Spark, the data-processing engine, is one example of Scala there: it offers a Scala API alongside Java, Python and R, and Spark 4.2.0 runs on Scala 2.13. Its documentation says that a Scala application must use the same Scala version that Spark was compiled for, which is why the Spark module of this track pins Scala 2.13 while every other module uses Scala 3.9.

Scala is a smaller language than Java or Python. In the 2025 Stack Overflow Developer Survey, 2.6 % of the 31,771 respondents to the question on programming languages chose Scala, and so did 2.8 % of the professional developers among them.

Scala Next moves forward, Scala LTS stays put

Scala 3 is released on two lines. The official download page lists Scala NextScala Next: The release line of Scala 3 that receives new language features, in regular minor releases such as 3.10 after 3.9., currently 3.10.0, as “the default to be used by most users”, and Scala LTSScala LTS: A long-term support line of Scala 3, such as 3.3 or 3.9. It receives only patch releases with fixes, for at least three years, and libraries are usually published with it., 3.9.0, as “advised to be used for publishing libraries”. Next is where the language develops: it receives regular minor releases, 3.8, 3.9 and 3.10, each with new features. An LTS line, in the words of the compatibility plan, “will only receive patch updates”: 3.9.1, 3.9.2 and so on, with fixes but no new features, for at least three years.

The project may name a new LTS line from the Next releases only after more than two years. 3.3 was the first, and 3.9 is the second. The Scala 3.9 announcement promises 3.9 at least three years of maintenance and keeps 3.3 LTS maintained for one more year after 3.9.0, with fewer fixes. Walk through the releases that shaped what a new project should use:

A newer Scala reads older output, never the other way round

Releases on one line are compatible in both directions: code compiled with 3.9.0 works with 3.9.2, and the other way round. Between minor versions only one direction works. The compatibility plan puts it as a rule: “Scala 3.b.y can consume the output of Scala 3.a.x only if b is greater or equal to a.”

Work it through for a library. Compiled with 3.3.8, it can be used by projects on 3.3, 3.9 and 3.10, because each of those minor versions is 3 or more. Compiled with 3.9.0, it reaches projects on 3.9 and 3.10, but a project still on 3.3 cannot read it, and the 3.9 announcement warns library authors of exactly that. Compiled with 3.10.0, it shuts out every 3.9 project too. An application has no such users, so it can take the newest version.

Answer the questions about your own project, and the table marks the versions that fit:

In short: an application can follow Scala Next, or stay on 3.9 LTS for fewer upgrades; a library is published with 3.9 LTS, or with 3.3.8 while its users still build with 3.3; and code that must still run on a JDK older than 17 stays on the 3.3 line, the only maintained line that still targets older JDKs, because from 3.8 on the compiler needs JDK 17.

Every recorded run in this track names its versions

The programs of this track do not run in your browser. Each one shows what it printed when it ran with Scala 3.9.0 on Eclipse Temurin 25.0.4.1, under the command that ran it, so you can type the same command on your own computer and compare. This session prints the versions behind every run: first the scala command’s own report, then a program that asks the running JVM:

// Reports what runs this program: the Scala library, the Java runtime and the platform.
@main def versionReport(): Unit =
  val scalaVersion = scala.util.Properties.versionNumberString
  val javaVersion = System.getProperty("java.version")
  val vendor = System.getProperty("java.vendor")
  println(s"Scala library   $scalaVersion")
  println(s"Java runtime    $javaVersion ($vendor)")
  println(s"Platform        ${System.getProperty("os.name")}, ${System.getProperty("os.arch")}")

from session import run

# The versions behind the recorded runs of this track: the scala command, then a program that reports what runs it.
run("""
scala version
cd report
scala run . --server=false
""")

$ scala version
Scala code runner version: 1.16.0
Scala version (default): 3.9.0
$ cd report
$ scala run . --server=false
Scala library   3.9.0
Java runtime    25.0.4.1 (Eclipse Adoptium)
Platform        Mac OS X, aarch64

Read the lines from the top. Scala code runner version: 1.16.0 is the version of the tool behind the scala command: since Scala 3.5 that command is Scala CLI, which compiles, runs, tests and packages code. Scala version (default): 3.9.0 is the compiler it uses when a project names no version. The program then reports the Scala library it found, 3.9.0, the Java runtime, Temurin 25.0.4.1 from the Eclipse Adoptium project, and the platform, macOS on an Arm processor (aarch64).

Two numbers can disagree on your computer, and both are worth knowing. The scala command may default to a newer Scala than the one a project asks for, and the JDK that runs your program may not be the first java on your PATH. The next lesson shows how each is chosen and how to pin them.

Practise: versions and platforms

Fifteen questions cover the five ideas above, from the files the compiler writes to the versions of a run. The session starts with whichever idea your answers show to be weakest, and each answer comes with its reason:

Interview questions

Fresher · What is the difference between Scala Next and Scala LTS, and which would you use for a new library?

Scala Next is the line where the language develops. It gets regular minor releases with new features, such as 3.8, 3.9 and 3.10, and each one supersedes the one before. Scala LTS is a long-term support line, first 3.3 and now 3.9: it gets only patch releases with fixes, for at least three years. The two matter most for libraries, because a Scala 3 minor version can use code compiled with the same or an older minor version, never a newer one. A library compiled with 3.10 can be used only from 3.10 on, while one compiled with 3.9 reaches every 3.9 and 3.10 project. So a new library is published with 3.9 LTS, or with 3.3.8 while important users still build with 3.3. An application has no downstream users, so it can follow Scala Next.

Key takeaways

• Scala 3 compiles to JVM bytecode in .class files, which any JDK 17 or newer runs, plus .tasty files that keep the full Scala types for later compilers and editors.
• The JVM is Scala’s main platform, where it can use every Java library; Scala.js compiles the same language to JavaScript and Scala Native to native programs.
• Scala Next, 3.10, receives new features in minor releases, while an LTS line, 3.3 and now 3.9, receives only fixes for at least three years.
• A Scala 3 minor version can use code compiled by the same or an older one, never a newer one, so libraries are published with 3.9 LTS and applications may follow Scala Next.
• The runs of this track used Scala 3.9.0, whose scala command is Scala CLI 1.16.0, on Temurin 25.0.4.1; the Spark module uses Scala 2.13, the version Spark is built for.