В чём разница между JDK, JRE и JVM?

Разница между JDK, JRE и JVM

Эти три аббревиатуры описывают три разных уровня Java-платформы: от абстрактной спецификации исполнения до полного набора инструментов разработчика. Важно понимать, что начиная с Java 9 граница между JRE и JDK стала менее чёткой.

JVM — Java Virtual Machine

JVM — это спецификация виртуальной машины, которая:

• загружает и верифицирует байткод (.class-файлы)
• интерпретирует байткод или компилирует его в нативный код через JIT (Just-In-Time Compiler)
• управляет памятью через Garbage Collector
• обеспечивает безопасность и изоляцию кода

Популярные реализации JVM: HotSpot (Oracle/OpenJDK), GraalVM, Eclipse OpenJ9, Azul Zing. JVM не умеет запускать .java-файлы напрямую — только скомпилированный байткод.

JRE — Java Runtime Environment

JRE = JVM + стандартная библиотека классов (rt.jar в Java 8, или модули в Java 9+). Предназначен для запуска Java-программ, но не для их разработки. Содержит:

• JVM
• Стандартные библиотеки: java.lang, java.util, java.io, java.net и т.д.
• Конфигурационные файлы, шрифты, локали

Начиная с Java 11, Oracle прекратила отдельную публикацию JRE. Теперь для production-развёртывания создают минимальный runtime с помощью jlink.

JDK — Java Development Kit

JDK = JRE + инструменты разработки. Это то, что устанавливают разработчики. Содержит:

• JRE (или аналогичные компоненты)
• javac — компилятор Java-исходников в байткод
• jar — упаковка в архивы
• javadoc — генератор документации
• jdb — отладчик
• jcmd, jstack, jmap, jstat — диагностические инструменты
• jlink — создание минимального кастомного runtime
• jshell — интерактивный REPL (с Java 9)

Визуальная схема вложения

JDK
+-- JRE
|   +-- JVM (HotSpot, OpenJ9, GraalVM...)
|   +-- Standard Libraries (java.*, javax.*)
+-- javac, jar, jlink, jshell, jcmd, jstack...

Практический пример: компиляция и запуск

# Компиляция (нужен JDK)
javac Hello.java       # создаёт Hello.class

# Запуск (достаточно JRE/JVM)
java Hello             # JVM загружает и выполняет байткод

# Создание минимального runtime для деплоя (JDK 9+)
jlink --add-modules java.base,java.net.http \
      --output /opt/minimal-jre
/opt/minimal-jre/bin/java -jar app.jar

В контексте Docker

Для production-образов используют eclipse-temurin:21-jre (содержит только JRE) вместо eclipse-temurin:21-jdk, чтобы уменьшить размер образа. Для сборки в multi-stage build нужен JDK:

# Dockerfile
FROM eclipse-temurin:21-jdk AS build
COPY . .
RUN ./gradlew bootJar

FROM eclipse-temurin:21-jre AS runtime
COPY --from=build /app/build/libs/app.jar /app.jar
CMD ["java", "-jar", "/app.jar"]

Подводные камни

• С Java 11 Oracle не публикует отдельный JRE-дистрибутив — при необходимости JRE-образа используйте Temurin/Adoptium или создавайте через jlink.
• Разные дистрибутивы JDK (Oracle JDK, OpenJDK, GraalVM, Azul Zulu) имеют одинаковый API, но могут различаться лицензиями и производительностью GC.
• Версия JDK в CI и JRE в production должны совпадать — байткод Java 21 не запустится на JVM Java 17 (UnsupportedClassVersionError).
• JAVA_HOME нередко указывает на JRE вместо JDK на некоторых дистрибутивах Linux — это ломает Maven/Gradle, которым нужен javac.
• При использовании GraalVM Native Image JVM фактически отсутствует в runtime — приложение компилируется в нативный бинарник и не использует байткод.
• jshell входит в JDK, но не в JRE — частая ошибка при попытке запустить REPL в production-контейнере.

• Путать термин «jdk jre jvm» с соседним механизмом Java.
• Не называть границу lifecycle, transaction, thread или request для «jdk jre jvm».
• Игнорировать production-эффекты «jdk jre jvm»: latency, SQL shape, memory, security или observability.

• Попросить объяснить механизм «jdk jre jvm» на минимальном примере.
• Проверить, видит ли кандидат failure mode и диагностику для «jdk jre jvm».
• Уточнить, какие настройки или API меняют «jdk jre jvm» в реальном сервисе.