streamalism.org

1. Introduktion

I denne korte vejledning lærer vi, hvad der forårsager Java-runtime-fejlen java.lang.UnsupportedClassVersionError: Ikke-understøttet major.minor version og hvordan man løser det.

2. Et kig på fejlen

Lad os starte med at se på en eksempelfejl:

Undtagelse i tråden "main" java.lang.UnsupportedClassVersionError: com / baeldung / MajorMinorApp er blevet kompileret af en nyere version af Java Runtime (klasse filversion 55.0), denne version af Java Runtime genkender kun klasse filversioner op til 52.0

Denne fejl fortæller os, at vores klasse blev samlet i en højere version af Java end den version, som vi forsøgte at køre den med. Mere specifikt, i dette tilfælde kompilerede vi vores klasse med Java 11 og forsøgte at køre den med Java 8.

2.1. Java-versionsnumre

Som reference, lad os tage et hurtigt kig på Java-versionsnumrene. Dette vil være praktisk, hvis vi har brug for at downloade den relevante Java-version.

De større og mindre versioner er gemt i klasse-bytekoden ved byte seks og syv.

Lad os se, hvordan de vigtigste versionsnumre kortlægges til Java-versioner:

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

3. Løs via kommandolinjen

Lad os nu diskutere, hvordan vi kan løse denne fejl, når vi kører Java fra kommandolinjen.

Afhængigt af vores situation, vi har to måder, hvorpå vi kan løse denne fejl: kompiler vores kode til en tidligere version af Java eller kør vores kode på en nyere Java-version.

Den endelige beslutning afhænger af vores situation. Hvis vi har brug for et tredjepartsbibliotek, der allerede er kompileret på et højere niveau, er vores bedste mulighed sandsynligvis at køre vores applikation ved hjælp af en nyere Java-version. Hvis vi pakker en applikation til distribution, kan det være bedst at kompilere ned til en ældre version.

3.1. JAVA_HOME Miljøvariabel

Lad os starte med at kontrollere, hvordan vores JAVA_HOME variabel er indstillet. Dette vil fortælle os, hvilken JDK der bruges, når vi kører javac fra vores kommandolinje:

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

Hvis vi er klar til at flytte helt til en nyere JDK, kan vi downloade den nyere version og sørge for, at vores STI og JAVA_HOME miljøvariabler er indstillet korrekt.

3.2. Kører en ny JRE

Vender vi tilbage til vores eksempel, lad os se på, hvordan vi kan løse fejlen ved at køre den i en højere version af Java. Forudsat at vi har Java 11 JRE i C: \ Apps \ jdk-11.0.2, kan vi køre vores kode med java kommando pakket med det:

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

3.3. Kompilering med en ældre JDK

Hvis vi skriver en applikation, som vi vil kunne køre ned til en bestemt version af Java, skal vi kompilere koden til den version.

Vi kan gøre det på en af ​​tre måder: ved hjælp af en ældre JDK til at kompilere vores kode ved hjælp af -stienklassesti, -kildeog -mål muligheder for javac kommando (JDK 8 og ældre) eller ved hjælp af -frigøre option (JDK 9 og nyere).

Lad os starte med at bruge en ældre JDK, ligesom hvordan vi brugte en nyere JRE til at køre vores kode:

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

Det er muligt bare at bruge -kilde og -mål, men det opretter muligvis stadig klassefiler, der ikke er kompatible med en ældre Java.

For at sikre kompatibilitet kan vi pege -stienklassesti ved rt.jar af den målrettede JRE:

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

Ovenstående gælder primært for JDK 8 og lavere. I JDK 9 er -frigøre parameter blev tilføjet for at erstatte -kilde og -mål. Det -frigøre option understøtter mål 6, 7, 8, 9, 10 og 11.

Lad os bruge -frigøre at målrette mod Java 8:

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

Nu kan vi køre vores kode på en Java 8 eller højere JRE.

4. Formørkelse IDE

Nu hvor vi forstår fejlen og den generelle tilgang til at rette den, lad os tage det, vi har lært, og se hvordan vi kan anvende den, når vi arbejder i Eclipse IDE.

4.1. Ændring af JRE

Forudsat at vi allerede har Eclipse konfigureret med forskellige versioner af Java, lad os ændre vores projekts JRE.

Lad os gå til vores Projektegenskaber, derefter til Java Build-stiog derefter Biblioteker fanen. Når vi er der, vælger vi JRE og klikker Redigere:

Lad os nu vælge Alternativ JRE og peg på vores Java 11-installation:

På dette tidspunkt kører vores applikation mod Java 11.

4.2. Ændring af kompilerniveau

Lad os nu se på, hvordan vi kan ændre vores mål til et lavere niveau af Java.

Lad os først gå tilbage til vores Projektegenskaber, derefter Java Compilerog tjek Aktivér projektspecifikke indstillinger:

Her kan vi indstille vores projekt til at kompilere til tidligere versioner af Java og tilpasse andre overholdelsesindstillinger:

5. IntelliJ IDEA

Vi kan også styre den version af Java, vi bruger til kompilering og kørsel i IntelliJ IDEA.

5.1. Tilføjelse af en JDK

Før vi gør det, ser vi, hvordan du tilføjer yderligere JDK'er. Lad os gå til Fil -> Projektstruktur -> Platformsindstillinger -> SDK'er:

Lad os klikke på plusikonet i den midterste kolonne, vælg JDK fra rullemenuen, og vælg vores JDK-placering:

5.2. Ændring af JRE

Først ser vi på, hvordan vi bruger IDEA til at køre vores projekt på den nyere JRE.

Lad os gå til Kør -> Rediger konfigurationer ... og ændre vores JRE til 11:

Nu, når vi kører vores projekt, kører det med Java 11 JRE.

5.3. Ændring af kompilerniveau

Hvis vi distribuerer vores applikation til at køre på en lavere JRE, er vi nødt til at justere vores kompilatorniveau for at målrette mod den ældre version af Java.

Lad os gå til File -> Project Structure… -> Project Settings -> Project og ændre vores Projekt SDK og Projektets sprogniveau:

Vi kan nu bygge vores projekt, og de genererede klassefiler kører på Java 8 og nyere.

6. Maven

Når vi bygger og pakker en fil i Maven, kan vi kontrollere den version af Java, vi målretter mod.

Når du bruger Java 8 eller ældre, indstiller vi kilden og målet for compiler-pluginet.

Lad os indstille kilden og målet ved hjælp af compiler plugin egenskaber:

 1.8 1.8 

Alternativt kan vi indstille kilden og målet i compiler-pluginet:

  maven-compiler-plugin 1.8 1.8 

Med -frigøre mulighed tilføjet i Java 9, kan vi også konfigurere det med Maven.

Lad os bruge en compiler-plugin-egenskab til at indstille frigøre:

 8 

Eller vi kan konfigurere compiler plugin direkte:

  maven-compiler-plugin 8 

7. Konklusion

I denne korte artikel lærte vi, hvad der forårsager java.lang.UnsupportedClassVersionError: Ikke-understøttet major.minor version fejlmeddelelse, og hvordan man løser det.