Slik løser du java.lang.UnsupportedClassVersionError

1. Introduksjon

I denne korte opplæringen skal vi lære hva som forårsaker Java-kjøretidsfeilen java.lang.UnsupportedClassVersionError: Ikke-støttet major.minor versjon og hvordan du fikser det.

2. En titt på feilen

La oss begynne med å se på en eksempelfeil:

Unntak i tråden "main" java.lang.UnsupportedClassVersionError: com / baeldung / MajorMinorApp har blitt samlet av en nyere versjon av Java Runtime (klassefilversjon 55.0), denne versjonen av Java Runtime gjenkjenner bare klassefilversjoner opp til 52.0

Denne feilen forteller oss at klassen vår ble samlet i en høyere versjon av Java enn den versjonen vi prøvde å kjøre den med. Mer spesifikt, i dette tilfellet, samlet vi klassen vår med Java 11 og prøvde å kjøre den med Java 8.

2.1. Java-versjonsnumre

Som referanse, la oss ta en rask titt på Java-versjonsnumrene. Dette vil være nyttig hvis vi trenger å laste ned riktig Java-versjon.

De største og mindre versjonsnumrene er lagret i klasse bytekode på byte seks og syv.

La oss se hvordan hovedversjonsnumrene tilordnes til Java-versjoner:

  • 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

La oss nå diskutere hvordan vi kan løse denne feilen når vi kjører Java fra kommandolinjen.

Avhengig av situasjonen vår, vi har to måter vi kan løse denne feilen på: kompiler koden vår for en tidligere versjon av Java, eller kjør koden vår på en nyere Java-versjon.

Den endelige avgjørelsen avhenger av situasjonen vår. Hvis vi trenger å bruke et tredjepartsbibliotek som allerede er samlet på et høyere nivå, er vårt beste alternativ sannsynligvis å kjøre applikasjonen vår ved hjelp av en nyere Java-versjon. Hvis vi pakker inn et program for distribusjon, kan det være best å kompilere ned til en eldre versjon.

3.1. JAVA_HOME Miljøvariabel

La oss starte med å sjekke hvordan vår JAVA_HOME variabel er satt. Dette vil fortelle oss hvilken JDK som brukes når vi løper javac fra kommandolinjen vår:

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

Hvis vi er klare til å flytte helt til en nyere JDK, kan vi laste ned den nyere versjonen og sørge for at vår STI og JAVA_HOME miljøvariabler er riktig innstilt.

3.2. Kjører en ny JRE

Når vi kommer tilbake til eksemplet vårt, la oss se på hvordan vi kan løse feilen ved å kjøre den i en høyere versjon av Java. Forutsatt at vi har Java 11 JRE i C: \ Apps \ jdk-11.0.2, kan vi kjøre koden vår med java kommando pakket med den:

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

3.3. Kompilering med en eldre JDK

Hvis vi skriver et program som vi ønsker å kunne kjøres ned til en bestemt versjon av Java, må vi kompilere koden for den versjonen.

Vi kan gjøre det på en av tre måter: bruke en eldre JDK til å kompilere koden vår, ved hjelp av -bootclasspath, -kilde, og -mål alternativene til javac kommando (JDK 8 og eldre), eller bruke -utgivelse alternativ (JDK 9 og nyere).

La oss begynne med å bruke en eldre JDK, på samme måte som vi brukte en nyere JRE for å kjøre koden vår:

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

Det er mulig å bare bruke -kilde og -mål, men det kan fremdeles opprette klassefiler som ikke er kompatible med en eldre Java.

For å sikre kompatibilitet kan vi peke -bootclasspathrt.jar av den målrettede JRE:

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

Ovennevnte gjelder hovedsakelig JDK 8 og lavere. I JDK 9 er -utgivelse parameter ble lagt til for å erstatte -kilde og -mål. De -utgivelse alternativet støtter mål 6, 7, 8, 9, 10 og 11.

La oss bruke -utgivelse for å målrette Java 8:

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

Nå kan vi kjøre koden vår på en Java 8 eller høyere JRE.

4. Formørkelse IDE

Nå som vi forstår feilen og den generelle tilnærmingen til å rette den, la oss ta det vi har lært, og se hvordan vi kan bruke den når vi jobber i formørkelses-IDE.

4.1. Endre JRE

Forutsatt at vi allerede har Eclipse konfigurert med forskjellige versjoner av Java, la oss endre prosjektets JRE.

La oss gå til vår Prosjektegenskaper, deretter til Java Build Path, og deretter Biblioteker fanen. Når du er der, velger vi JRE og klikker Redigere:

La oss nå velge Alternativ JRE og pek på vår Java 11-installasjon:

På dette tidspunktet vil applikasjonen vår kjøre mot Java 11.

4.2. Endring av kompilatornivå

La oss nå se på hvordan vi kan endre målet vårt til et lavere nivå av Java.

La oss først gå tilbake til vår Prosjektegenskaper, deretter Java Compiler, og sjekk Aktiver prosjektspesifikke innstillinger:

Her kan vi stille prosjektet vårt til å kompilere for tidligere versjoner av Java og tilpasse andre samsvarsinnstillinger:

5. IntelliJ IDEA

Vi kan også kontrollere versjonen av Java vi bruker for å kompilere og kjøre i IntelliJ IDEA.

5.1. Legge til en JDK

Før vi gjør det, får vi se hvordan du legger til flere JDK-er. La oss gå til Fil -> Prosjektstruktur -> Plattforminnstillinger -> SDKer:

La oss klikke på pluss-ikonet i den midterste kolonnen, velg JDK fra rullegardinmenyen, og velg vår JDK-plassering:

5.2. Endre JRE

Først skal vi se på hvordan vi kan bruke IDEA til å kjøre prosjektet vårt på den nyere JRE.

La oss gå til Kjør -> Rediger konfigurasjoner ... og endre vår JRE til 11:

Nå, når vi kjører prosjektet vårt, vil det kjøre med Java 11 JRE.

5.3. Endring av kompilatornivå

Hvis vi distribuerer applikasjonen vår for å kjøre på en lavere JRE, må vi justere kompilatornivået vårt for å målrette mot den eldre versjonen av Java.

La oss gå til Fil -> Prosjektstruktur ... -> Prosjektinnstillinger -> Prosjekt og endre vår Prosjekt SDK og Prosjektets språknivå:

Vi kan nå bygge prosjektet vårt, og klassefilene som genereres vil kjøre på Java 8 og nyere.

6. Maven

Når vi bygger og pakker en fil i Maven, kan vi kontrollere versjonen av Java vi målretter mot.

Når du bruker Java 8 eller eldre, setter vi kilden og målet for kompilator-pluginet.

La oss angi kilde og mål ved hjelp av kompilator-plugin-egenskaper:

 1.8 1.8 

Alternativt kan vi stille kilden og målet i kompilator-pluginet:

  maven-compiler-plugin 1.8 1.8 

Med -utgivelse alternativet lagt til i Java 9, kan vi også konfigurere det med Maven.

La oss bruke en kompilator-plugin-egenskap for å stille inn utgivelse:

 8 

Eller vi kan konfigurere kompilatortillegget direkte:

  maven-compiler-plugin 8 

7. Konklusjon

I denne korte artikkelen lærte vi hva som forårsaker java.lang.UnsupportedClassVersionError: Ikke-støttet major.minor versjon feilmelding, og hvordan du løser det.


$config[zx-auto] not found$config[zx-overlay] not found