Hoe java.lang.UnsupportedClassVersionError

1. Inleiding

In deze korte tutorial gaan we leren wat de oorzaak is van de Java-runtime-fout java.lang.UnsupportedClassVersionError: niet-ondersteunde major.minor-versie en hoe u dit kunt oplossen.

2. Een blik op de fout

Laten we beginnen met een voorbeeldfout te bekijken:

Uitzondering in thread "main" java.lang.UnsupportedClassVersionError: com / baeldung / MajorMinorApp is gecompileerd door een recentere versie van de Java Runtime (klassebestandsversie 55.0), deze versie van de Java Runtime herkent alleen klassebestandsversies tot 52.0

Deze fout vertelt ons dat onze klasse is gecompileerd met een hogere versie van Java dan de versie waarmee we het probeerden uit te voeren. Meer specifiek hebben we in dit geval onze klasse gecompileerd met Java 11 en geprobeerd deze uit te voeren met Java 8.

2.1. Java-versienummers

Laten we ter referentie even kijken naar de Java-versienummers. Dit is handig als we de juiste Java-versie moeten downloaden.

De primaire en secundaire versienummers worden opgeslagen in de bytecode van de klasse op bytes zes en zeven.

Laten we eens kijken hoe de belangrijkste versienummers worden toegewezen aan Java-versies:

  • 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. Herstel via de opdrachtregel

Laten we nu bespreken hoe we deze fout kunnen oplossen bij het uitvoeren van Java vanaf de opdrachtregel.

Afhankelijk van onze situatie, we hebben twee manieren om deze fout op te lossen: compileer onze code voor een eerdere versie van Java, of voer onze code uit op een nieuwere Java-versie.

De uiteindelijke beslissing hangt af van onze situatie. Als we een bibliotheek van derden moeten gebruiken die al op een hoger niveau is gecompileerd, is onze beste optie waarschijnlijk om onze applicatie uit te voeren met een nieuwere Java-versie. Als we een applicatie verpakken voor distributie, is het misschien het beste om naar een oudere versie te compileren.

3.1. JAVA_HOME Omgevingsvariabele

Laten we beginnen met te kijken hoe onze JAVA_HOME variabele is ingesteld. Dit zal ons vertellen welke JDK wordt gebruikt wanneer we draaien Javac vanaf onze opdrachtregel:

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

Als we klaar zijn om volledig naar een nieuwere JDK te gaan, kunnen we de nieuwere versie downloaden en ervoor zorgen dat onze PAD en JAVA_HOME omgevingsvariabelen zijn op de juiste manier ingesteld.

3.2. Een nieuwe JRE uitvoeren

Laten we teruggaan naar ons voorbeeld en kijken hoe we de fout kunnen oplossen door deze op een hogere versie van Java uit te voeren. Ervan uitgaande dat we Java 11 JRE in C: \ Apps \ jdk-11.0.2kunnen we onze code uitvoeren met de Java commando erbij verpakt:

C: \ Apps \ jdk-11.0.2 \ bin \ java com.baeldung.MajorMinorApp Hallo wereld!

3.3. Compileren met een oudere JDK

Als we een applicatie schrijven die we naar een bepaalde versie van Java willen laten draaien, moeten we de code voor die versie compileren.

We kunnen dat op drie manieren doen: een oudere JDK gebruiken om onze code te compileren, met behulp van de -bootclasspath, -bron, en -doelwit opties van de Javac commando (JDK 8 en ouder), of gebruik de -vrijlating optie (JDK 9 en nieuwer).

Laten we beginnen met het gebruik van een oudere JDK, vergelijkbaar met hoe we een nieuwere JRE hebben gebruikt voor het uitvoeren van onze code:

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

Het is mogelijk om gewoon te gebruiken -bron en -doelwit, maar het kan nog steeds klassebestanden maken die niet compatibel zijn met een oudere Java.

Om compatibiliteit te garanderen, kunnen we wijzen -bootclasspath bij de rt.jar van de beoogde JRE:

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

Het bovenstaande is voornamelijk van toepassing op JDK 8 en lager. In JDK 9 is het -vrijlating parameter is toegevoegd om te vervangen -bron en -doelwit. De -vrijlating optie ondersteunt doelen 6, 7, 8, 9, 10 en 11.

Laten we gebruiken -vrijlating om Java 8 te targeten:

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

Nu kunnen we onze code uitvoeren op een Java 8 of hoger JRE.

4. Eclipse IDE

Nu we de fout begrijpen en de algemene aanpak om deze te corrigeren, laten we eens kijken naar wat we hebben geleerd en kijken hoe we deze kunnen toepassen bij het werken in de Eclipse IDE.

4.1. Veranderen van de JRE

Ervan uitgaande dat we Eclipse al hebben geconfigureerd met verschillende versies van Java, laten we de JRE van ons project wijzigen.

Laten we naar onze gaan Projecteigenschappen, dan naar Java-buildpad, en vervolgens de Bibliotheken tabblad. Eenmaal daar selecteren we de JRE en klikken Bewerk:

Laten we nu kiezen Alternatieve JRE en wijs naar onze Java 11-installatie:

Op dit punt werkt onze applicatie tegen Java 11.

4.2. Het compilerniveau wijzigen

Laten we nu kijken hoe we ons doel kunnen veranderen naar een lager Java-niveau.

Laten we eerst teruggaan naar onze Projecteigenschappen, dan Java-compiler, en check Schakel projectspecifieke instellingen in:

Hier kunnen we ons project zo instellen dat het compileert voor eerdere versies van Java en andere nalevingsinstellingen aanpassen:

5. IntelliJ IDEE

We kunnen ook de versie van Java beheren die we gebruiken voor compileren en uitvoeren in IntelliJ IDEA.

5.1. Een JDK

Voordat we dat doen, zullen we zien hoe we extra JDK's kunnen toevoegen. Laten we gaan naar Bestand -> Projectstructuur -> Platforminstellingen -> SDK's:

Laten we op het pluspictogram in de middelste kolom klikken, selecteer het JDK uit de vervolgkeuzelijst en selecteer onze JDK-locatie:

5.2. Veranderen van de JRE

Eerst kijken we hoe we IDEA kunnen gebruiken om ons project op de nieuwere JRE uit te voeren.

Laten we gaan naar Uitvoeren -> Configuraties bewerken… en verander onze JRE tot 11:

Als we ons project nu uitvoeren, wordt het uitgevoerd met de Java 11 JRE.

5.3. Het compilerniveau wijzigen

Als we onze applicatie distribueren om op een lagere JRE te draaien, moeten we ons compilerniveau aanpassen om de oudere versie van Java te targeten.

Laten we gaan naar Bestand -> Projectstructuur… -> Projectinstellingen -> Project en verander onze Project SDK en Project taalniveau:

We kunnen nu ons project bouwen en de gegenereerde klassebestanden zullen op Java 8 en hoger worden uitgevoerd.

6. Maven

Wanneer we een bestand in Maven bouwen en verpakken, kunnen we bepalen op welke versie van Java we ons richten.

Als u Java 8 of ouder gebruikt, stellen we de bron en het doel voor de compiler-plug-in in.

Laten we de bron en het doel instellen met behulp van de eigenschappen van de compilerplug-in:

 1.8 1.8 

Als alternatief kunnen we de bron en het doel instellen in de compiler-plug-in:

  maven-compiler-plugin 1.8 1.8 

Met de -vrijlating optie toegevoegd in Java 9, we kunnen dat ook met Maven configureren.

Laten we een compiler-plugin-eigenschap gebruiken om de vrijlating:

 8 

Of we kunnen de compiler-plug-in rechtstreeks configureren:

  maven-compiler-plugin 8 

7. Conclusie

In dit korte artikel hebben we geleerd wat de oorzaak is van de java.lang.UnsupportedClassVersionError: niet-ondersteunde major.minor-versie foutmelding en hoe u deze kunt oplossen.


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