# The Anatomy of ct.sym -- How javac Ensures Backwards Compatibility

DevFeed: [The Anatomy of ct.sym -- How javac Ensures Backwards Compatibility](<https://devfeed.tech/articles/the-anatomy-of-ct-sym-how-javac-ensures-backwards-compatibility-18877.md>)

Original publisher: [Read original article](<https://www.morling.dev/blog/the-anatomy-of-ct-sym-how-javac-ensures-backwards-compatibility/>)

Published: 2021-04-26T17:45:00Z

Content type: tutorial

Language: en

Sources: [Gunnar Morling](<https://devfeed.tech/sources/gunnar-morling.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [compatibility](<https://devfeed.tech/tags/compatibility.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [java](<https://devfeed.tech/tags/java.md>), [jdk](<https://devfeed.tech/tags/jdk.md>)

## AI overview

This article explains how Java maintains backward compatibility across JDK versions. It shows why matching bytecode levels is not enough, because compiled code may use APIs unavailable in the target runtime, and explains how Java 9's --release option provides safer, more portable compilation for older Java versions.

## Source excerpt

One of the ultimate strengths of Java is its strong notion of backwards compatibility: Java applications and libraries built many years ago oftentimes run without problems on current JVMs, and the compiler of current JDKs can produce byte code, that is executable with earlier Java versions. For instance, JDK 16 supports byte code levels going back as far as to Java 1.7; But: hic sunt dracones. The emitted byte code level is just one part of the story. It's equally important to consider which APIs of the JDK are used by the compiled code, and whether they are available in the targeted Java runtime version. As an example, let's consider this simple "Hello World" program: