Java lang unsupportedclassversionerror version

Как исправить java.lang.Ошибка UnsupportedClassVersionError

Узнайте, что вызывает “java.lang.Ошибка UnsupportedClassVersionError: Неподдерживаемая ошибка основной.второстепенной версии” сообщение и способы ее исправления.

1. введение

В этом коротком уроке мы узнаем, что вызывает ошибку Java во время выполнения java.lang.UnsupportedClassVersionError: Неподдерживаемая основная.второстепенная версия и как это исправить.

Дальнейшее чтение:

Не удалось найти или загрузить основную ошибку класса

Ошибка компилятора Java: “ожидаемый класс, интерфейс или перечисление”

Причины и предотвращение java.lang.Ошибка проверки

2. Взгляните на ошибку

Давайте начнем с рассмотрения примера ошибки:

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/baeldung/MajorMinorApp has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Эта ошибка говорит нам о том, что наш класс был скомпилирован на более высокой версии Java, чем версия, с которой мы пытались его запустить. Более конкретно, в данном случае мы скомпилировали наш класс с Java 11 и попытались запустить его с Java 8.

2.1. Номера версий Java

Для справки, давайте быстро взглянем на номера версий Java. Это пригодится в случае, если нам понадобится загрузить соответствующую версию Java.

Основные и второстепенные номера версий хранятся в байт-коде класса в байтах шесть и семь.

Давайте посмотрим, как основные номера версий соотносятся с версиями Java:

3. Исправьте ошибку с помощью командной строки

Теперь давайте обсудим, как мы можем устранить эту ошибку при запуске Java из командной строки.

В зависимости от вашей ситуации у нас есть два способа устранить эту ошибку: скомпилировать наш код для более ранней версии Java или запустить наш код на более новой версии Java .

Окончательное решение зависит от вашей ситуации. Если нам нужно использовать стороннюю библиотеку, которая уже была скомпилирована на более высоком уровне, нашим лучшим вариантом, вероятно, является запуск нашего приложения с использованием более новой версии Java. Если мы упаковываем приложение для распространения, возможно, лучше всего скомпилировать его до более старой версии.

3.1. Переменная среды JAVA_HOME

Давайте начнем с проверки того, как установлена наша переменная JAVA_HOME . Это подскажет нам, какой JDK используется, когда мы запускаем javac из нашей командной строки:

echo %JAVA_HOME% C:\Apps\Java\jdk8-x64

Если мы готовы полностью перейти на более новую JDK , мы можем загрузить более новую версию и убедиться, что наши ПУТЬ и Переменные среды JAVA_HOME установлены соответствующим образом .

3.2. Запуск нового JRE

Возвращаясь к нашему примеру, давайте посмотрим, как мы можем устранить ошибку, запустив ее на более поздней версии Java. Предполагая, что у нас есть Java 11 JRE в C:\Apps\jdk-11.0.2 , мы можем запустить ваш код с помощью команды java , упакованной вместе с ним:

C:\Apps\jdk-11.0.2\bin\java com.baeldung.MajorMinorApp Hello World!

3.3. Компиляция С более старым JDK

Если мы пишем приложение, которое хотим запустить до определенной версии Java, нам нужно скомпилировать код для этой версии.

Мы можем сделать это одним из трех способов: используя более старый JDK для компиляции нашего кода; используя -bootclasspath , -исходный и -целевой параметры команды javac (JDK 8 и старше); или используя параметр –release (JDK 9 и новее).

Давайте начнем с использования более старого JDK, аналогично тому, как мы использовали более новую JRE для запуска нашего кода:

C:\Apps\Java\jdk1.8.0_31\bin\javac com/baeldung/MajorMinorApp.java

Можно просто использовать -исходный код и -целевой , но это все равно может привести к созданию файлов классов, несовместимых со старой Java.

Чтобы обеспечить совместимость, мы можем указать -bootclasspath на rt.jar целевого JRE:

javac -bootclasspath "C:\Apps\Java\jdk1.8.0_31\jre\lib\rt.jar" \ -source 1.8 -target 1.8 com/baeldung/MajorMinorApp.java

Вышесказанное относится в основном к JDK 8 и ниже. В JDK 9 параметр –release был добавлен для замены -источника и -цели . Опция –выпуск поддерживает целевые объекты 6, 7, 8, 9, 10, и 11.

Давайте используем –release для таргетинга Java 8:

javac --release 8 com/baeldung/MajorMinorApp.java

Теперь мы можем запускать наш код на Java 8 или выше JRE.

4. Среда разработки Eclipse

Теперь, когда мы понимаем ошибку и общий подход к ее исправлению, давайте возьмем то, что мы узнали, и посмотрим, как мы можем применить ее при работе в среде разработки Eclipse.

4.1. Изменение JRE

Предполагая , что у нас уже есть Eclipse, настроенный на разные версии Java, давайте изменим JRE нашего проекта.

Давайте перейдем к вашим Свойствам проекта , затем Пути сборки Java , а затем на вкладку Библиотеки . Оказавшись там, мы выберем JRE и нажмем Редактировать :

Теперь давайте выберем Альтернативный JRE и укажем на нашу установку Java 11:

На этом этапе наше приложение будет работать с Java 11.

4.2. Изменение уровня компилятора

Теперь давайте посмотрим, как мы можем изменить нашу цель на более низкий уровень Java.

Во-первых, давайте вернемся к нашим Свойствам проекта , затем Компилятору Java , а затем проверим Включить настройки для конкретного проекта :

Здесь мы можем настроить компиляцию вашего проекта для более ранних версий Java и настроить другие параметры соответствия:

5. ИДЕЯ IntelliJ

Мы также можем контролировать версию Java, которую мы используем для компиляции и запуска в IntelliJ IDEA.

5.1. Добавление JDK

Прежде чем мы это сделаем, мы посмотрим, как добавить дополнительные JDK. Давайте перейдем в Файл -> Структура проекта -> Настройки платформы -> SDKs :

Давайте щелкнем значок плюса в средней колонке, выберем JDK из раскрывающегося списка и выберем наше местоположение JDK:

5.2. Изменение JRE

Сначала мы рассмотрим, как использовать IDEA для запуска нашего проекта на более новой JRE.

Давайте перейдем в Выполнить -> Редактировать конфигурации… и измените наш JRE на 11:

Теперь, когда мы запускаем наш проект, он будет работать с Java 11 JRE.

5.3. Изменение уровня компилятора

Если мы распространяем наше приложение для работы на более низком ИЛИ, нам необходимо настроить уровень компилятора для более старой версии Java.

Давайте перейдем в Файл -> Структура проекта… -> Настройки проекта -> Проект и изменим наш SDK проекта и Уровень языка проекта :

Теперь мы можем создать ваш проект, и созданные файлы классов будут работать на Java 8 и выше.

6. Maven

Когда мы создаем и упаковываем файл в Maven , мы можем контролировать версию Java, на которую мы нацелены.

При использовании Java 8 или более поздней версии мы устанавливаем источник и цель для плагина компилятора.

Давайте установим источник и цель, используя свойства плагина компилятора:

В качестве альтернативы мы можем установить источник и цель в плагине компилятора:

  maven-compiler-plugin 1.8 1.8   

С –отпустите опция добавлена в Java 9, мы также можем настроить ее с помощью Maven.

Давайте используем свойство плагина компилятора для установки выпуска :

Или мы можем настроить плагин компилятора напрямую:

7. Заключение

В этой статье мы узнали, что вызывает java.lang.Ошибка UnsupportedClassVersionError: Неподдерживаемая основная.второстепенная версия сообщение об ошибке и способы ее исправления.

Читайте ещё по теме:

Источник

How to Fix the Unsupported Class Version Runtime Error in Java

Runtime errors occur when a program is being executed and, in the case of compiled languages, after the program has been successfully compiled. Runtime errors are, therefore, harder to detect and prevent than compile-time errors [1]. In Java, some of these runtime errors (namely throwable objects which are not exceptions) are triggered at a very early stage, while the program is basically starting up. Namely, there is a process of dynamic loading, linking, and initializing of classes and interfaces by the Java Virtual Machine (JVM) that occurs at the very beginning of execution of any Java application [2]. This allows for a certain category of errors to be captured and dealt with before the program effectively starts.

This category of high level runtime errors in Java is represented by classes which are direct descendants of the java.lang.Error class [3], including the java.lang.LinkageError class which denotes errors occurring during the aforementioned startup process [4]. An instance of the Error class (or any of its subclasses) is a throwable object that a program is not expected or advised to handle, but instead, should cause immediate termination of the program. This is because most of these errors occur as a result of abnormal conditions, often so severe that it is impossible to know or control what further execution of the program might do. LinkageError instances in particular indicate critical class-related errors triggered during the class linking phase of the startup process, usually as a consequence of some post-compilation changes in the bytecode or the Java environment.

What is the UnsupportedClassVersionError Error and Why Does it Happen?

The java.lang.UnsupportedClassVersionError class extends java.lang.ClassFormatError which is thrown whenever the JVM attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file [5][6]. As per Java’s error class hierarchy (Figure 1), an instance of UnsupportedClassVersionError is also a LinkageError which means that the error is identified during the JVM class linking process.

The specific issue that the UnsupportedClassVersionError error raises is the detection of a class file which had been compiled with a newer version of Java than the one used to run it. For instance, if a specific .class file has been compiled with Java Development Kit (JDK) 15, trying to run it with Java Runtime Environment (JRE) 8 will trigger the UnsupportedClassVersionError error. This almost invariably happens when someone attempts to run a program with a JDK or a JRE version that is incompatible with, i.e., lower than the Java version in which the code was compiled.

How to Fix the UnsupportedClassVersionError Error

The solution to the UnsupportedClassVersionError error generally boils down to two options:

• Run the code with a newer version of Java/JRE, or
• Recompile the code with an older Java/JDK compiler.

As a variant of #2, recompiling the code can also be done by specifying the “target” or “release” parameter of a newer Java/JDK compiler to an earlier version of Java, to produce backward-compatible bytecode.

Before recompiling any code, it is important to know the runtime version of both the already compiled code and the environment in which it needs to run on. The message accompanying the UnsupportedClassVersionError error provides this information in the form of class file versions, which can be mapped directly to a specific Java version, using the values from the table below.

Maven Projects

When dealing with Maven projects, which the majority of both small and large enterprise Java programs are, it is possible to control the Java version targeted by the compilation process from the Maven configuration, i.e. Maven Project Object Model (POM) file. The relevant settings are shown in the Figure below.

Note that while it is possible to control the source and target versions independently, it is recommended to set them to equal values, as backward compatibility of the compiled bytecode cannot be guaranteed [8].

Can Constructors Throw Exceptions in Java

How to Fix and Avoid NullPointerException in Java

How to Fix «Illegal Start of Expression» in Java

«Rollbar allows us to go from alerting to impact analysis and resolution in a matter of minutes. Without it we would be flying blind.»

Источник