Как исправить exception in thread main java lang unsupportedclassversionerror

This was a fresh linux Mint xfce machine

I have been battling this for a about a week. I’m trying to learn Java on Netbeans IDE and so naturally I get the combo file straight from Oracle. Which is a package of the JDK and the Netbeans IDE together in a tar file located here.

located
http://www.oracle.com/technetwork/java/javase/downloads/index.html
file name
JDK 8u25 with NetBeans 8.0.1

after installing them (or so I thought) I would make/compile a simple program like «hello world» and that would spit out a jar file that you would be able to run in a terminal. Keep in mind that the program ran in the Netbeans IDE.

I would end up with this error: java.lang.UnsupportedClassVersionError:

Even though I ran the file from oracle website I still had the old version of the Java runtime which was not compatible to run my jar file which was compiled with the new java runtime.

After messing with stuff that was mostly over my head from setting Paths to editing .bashrc with no remedy.

I came across a solution that was easy enough for even me. I have come across something that auto installs java and configures it on your system and it works with the latest 1.8.*

One of the steps is adding a PPA wasn’t sure about this at first but seems ok as it has worked for me

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java8-installer

domenic@domenic-AO532h ~ $ java -version
java version «1.8.0_25»
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) Server VM (build 25.25-b02, mixed mode)

I think it also configures the browser java as well.

I hope this helps others.

Если вы сталкивались с ошибками Exception in thread “main”, то в этой статье я расскажу что это значит и как исправить ее на примерах.

При работе в среде Java, типа Eclipse или Netbeans, для запуска java-программы, пользователь может не столкнуться с этой проблемой, потому что в этих средах предусмотрен качественный запуск с правильным синтаксисом и правильной командой.

Здесь мы рассмотрим несколько общих java-исключений(Exceptions) в основных исключениях потоков, которые вы можете наблюдать при запуске java-программы с терминала.

Это исключение происходит, когда ваш класс java компилируется из другой версии JDK и вы пытаетесь запустить его из другой версии java. Рассмотрим это на простом примере:

package com.journaldev.util;

public class ExceptionInMain {

public static void main() {
System.out.println(10);
}

}

Когда создаётся проект в Eclipse, он поддерживает версию JRE, как в Java 7, но установлен терминал Jawa 1.6. Из-за настройки Eclipse IDE JDK, созданный файл класса компилируется с Java 1.7.

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

pankaj@Pankaj:~/Java7Features/bin$java com/journaldev/util/ExceptionInMain
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/journaldev/util/ExceptionInMain : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Если запустить версию Java1.7, то это исключение не появится. Смысл этого исключения – это невозможность компилирования java-файла с более свежей версии на устаревшей версии JRE.

Исключение java.lang.NoClassDefFoundError

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

Обратите внимание: если написать: .class в следующую команду для запуска программы – это вызовет ошибку NoClassDefFoundError. Причина этой ошибки — когда не удается найти файл класса для выполнения Java.

pankaj@Pankaj:~/CODE/Java7Features/bin$java com/journaldev/util/ExceptionInMain.class

Exception in thread "main" java.lang.NoClassDefFoundError: com/journaldev/util/ExceptionInMain/class

Caused by: java.lang.ClassNotFoundException: com.journaldev.util.ExceptionInMain.class

at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Второй тип исключения происходит, когда Класс не найден.

pankaj@Pankajs-MacBook-Pro:~/CODE/Java7Features/bin/com/journaldev/util$java ExceptionInMain

Exception in thread "main" java.lang.NoClassDefFoundError: ExceptionInMain (wrong name: com/journaldev/util/ExceptionInMain)

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:791)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)

at java.net.URLClassLoader.access$100(URLClassLoader.java:71)

at java.net.URLClassLoader$1.run(URLClassLoader.java:361)

at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

at java.lang.ClassLoader.loadClass(ClassLoader.java:423)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)

at java.lang.ClassLoader.loadClass(ClassLoader.java:356)

at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:480)

Обратите внимание, что класс ExceptionInMain находится в пакете com.journaldev.util, так что, когда Eclipse компилирует этот класс, он размещается внутри /com/journaldev/util. Следовательно: класс не найден. Появится сообщение об ошибке.

Подробнее узнать об ошибке java.lang.NoClassDefFoundError.

Исключение java.lang.NoSuchMethodError: main

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

pankaj@Pankaj:~/CODE/Java7Features/bin$ java com/journaldev/util/ExceptionInMain

Error: Main method not found in class com.journaldev.util.ExceptionInMain, please define the main method as:

public static void main(String[] args)

Exception in thread "main" java.lang.ArithmeticException

Всякий раз, когда происходит исключение из метода main – программа выводит это исключение на консоль.

В первой части сообщения поясняется, что это исключение из метода main, вторая часть сообщения указывает имя класса и затем, после двоеточия, она выводит повторно сообщение об исключении.

Например, если изменить первоначальный класс появится сообщение System.out.println(10/0); Программа укажет на арифметическое исключение.

Exception in thread "main" java.lang.ArithmeticException: / by zero

at com.journaldev.util.ExceptionInMain.main(ExceptionInMain.java:6)

Методы устранения исключений в thread main

Выше приведены некоторые из распространенных исключений Java в потоке main, когда вы сталкиваетесь с одной из следующих проверок:

1. Эта же версия JRE используется для компиляции и запуска Java-программы.
2. Вы запускаете Java-класс из каталога классов, а пакет предоставляется как каталог.
3. Ваш путь к классу Java установлен правильно, чтобы включить все классы зависимостей.
4. Вы используете только имя файла без расширения .class при запуске.
5. Синтаксис основного метода класса Java правильный.



Автор оригинала: Amy DeGregorio.

1. введение

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

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

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

Причины и предотвращение 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:

• 45 1.1
• 46 1.2
• 47 1.3
• 48 1.4
• 49 5
• 50 6
• 51 7
• 52 8
• 53 9
• 54 10
• 55 11
• 56 12
• 57 13

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

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

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

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

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

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

echo %JAVA_HOME%
C:AppsJavajdk8-x64

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

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

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

C:Appsjdk-11.0.2binjava com.baeldung.MajorMinorApp
Hello World!

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

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

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

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

C:AppsJavajdk1.8.0_31binjavac com/baeldung/MajorMinorApp.java

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

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

javac -bootclasspath "C:AppsJavajdk1.8.0_31jrelibrt.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: Неподдерживаемая основная.второстепенная версия сообщение об ошибке и способы ее исправления.

1. Cause of the java.lang.UnsupportedClassVersionError
2. Fix the java.lang.UnsupportedClassVersionError

This tutorial demonstrates the Exception in thread main java.lang.UnsupportedClassVersionError error in Java.

Cause of the java.lang.UnsupportedClassVersionError

The UnsupportedClassVersionError is a sub-class of the ClassFormatError exception, which is thrown when JVM tries to read a class and finds that the class file is malformed or the file cannot be interpreted as a class. Here is the hierarchy of the UnsupportedClassVersionError exception:

Java.Lang.Object
    Java.Lang.Throwable
        Java.Lang.Error
            Java.Lang.LinkageError
                Java.Lang.ClassFormatError
                    Java.Lang.UnsupportedClassVersionError

The UnsupportedClassVersionError exception is specific to detecting a class file run by a lower version of Java before and now run by a newer version.

For example, suppose a Java file was run by JDK 12 and now by a newer JRE 8. In that case, it will throw the UnsupportedClassVersionError exception, or if we compile the class using Java version 1.8 and compile it using Java 1.7, it will throw the same error.

Let’s try an example in a class compiled by the newer version of Java and then run by an older version. See example:

public class Unsupported_Class_Version_Error{
    public static void main(String args[]) {
        System.out.println("Hello this is Delftstack.com");
    }
}

The code above will throw the UnsupportedClassVersionError as shown below:

Exception in thread "main" java.lang.UnsupportedClassVersionError: Unsupported_Class_Version_Error : Unsupported major.minor version 52.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)

The output shows the error because the code is compiled at Java 1.8 and executed at Java 1.7. That is why Exception in thread "main" java.lang.UnsupportedClassVersionError: Unsupported_Class_Version_Error : Unsupported major.minor version 52.0 will be thrown.

Fix the java.lang.UnsupportedClassVersionError

There are two conditions for this error, so the solution lies in these two conditions:

1. Run the code with the latest JDK and JRE.
2. Compile the code with the older version of JDK to match the runtime JDK.
3. One simple solution is to use the Java Cross Compilation. If the Production Environment JDK is lower than the Build Environment, we can generate a class file with a lower version using cross-compilation.

The following command will be used to create a class file for the code above:

javac -target 1.7 Unsupported_Class_Version_Error.java

As mentioned above, the solution is to build the application with the same versions at compile and runtime, or at least the compile-time version is lower than the runtime version.

The error above shows the Major Minor versions problem. Major Minor versions are the versions of JRE; for example, for JRE 8, the Major version is 52.0.

We must ensure no Major Minor version problems occur while compiling and executing the Java Class file. The list for the versions of JRE which are compatible with the class are:

Java SE 17 = 61,
Java SE 16 = 60,
Java SE 15 = 59,
Java SE 14 = 58,
Java SE 13 = 57,
Java SE 12 = 56,
Java SE 11 = 55,
Java SE 10 = 54,
Java SE 9 = 53,
Java SE 8 = 52,
Java SE 7 = 51,
Java SE 6.0 = 50,
Java SE 5.0 = 49,
JDK 1.4 = 48,
JDK 1.3 = 47,
JDK 1.2 = 46,
JDK 1.1 = 45