UnsupportedClassVersionError

[Big Womly]

Ik ben voor een klant een testing framework aan het opzetten. De PC die ik heb gekregen draait Java 1.7 en dit was dan ook de initiële versie waarin ik ben beginnen ontwikkelen. Bij overdracht naar de klant kreeg ik echter een UnsupportedClassVersionError, waardoor ik te weten ben gekomen dat de officiële java versie die ondersteund wordt 1.6.0_30 is.

Ik heb in de project properties dezelfde javaversie toegevoegd


(de -32 staat voor de 32-bit versie)

Desondanks krijg ik nog steeds dezelfde foutmelding bij het overbrengen van de jar

code:

D:\olivia-test_1.52>java -Xmx1024m -Xms256m -jar olivia-test.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: be/dieteren/pvu/frontend/app/MainApplication : 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)
        at be.dieteren.pvu.test.application.Application.startup(Application.java:59)
        at be.dieteren.pvu.test.TestRunner.main(TestRunner.java:38)

51 zou overeenkomen met versie 7, maar bij het exporteren had eclipse toch de 1.6.0_30 moeten nemen?

Java versie op de PC van de klant (Windows XP)

code:

D:\olivia-test_1.52>java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)

Java versie op mijn PC (Windows 7)

code:

C:\Users\msaerens>java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

De default JRE in eclipse staat nog wel op Java 1.7 x64

Wat zie ik nog over het hoofd?

[LinuX-TUX]

Big Womly schreef op vrijdag 20 december 2013 @ 09:42:
[...]
51 zou overeenkomen met versie 7, maar bij het exporteren had eclipse toch de 1.6.0_30 moeten nemen?

[...]

Waar baseer je dit op? Heeft Eclipse een autosense plugin welke deze versie pakt? Hoe ziet je jar build / export eruit?

1 google query levert me overigens het antwoord al en ik zal je een hint geven; "Compliance"

[Merethil]

Big Womly schreef op vrijdag 20 december 2013 @ 09:42:
Ik ben voor een klant een testing framework aan het opzetten. De PC die ik heb gekregen draait Java 1.7 en dit was dan ook de initiële versie waarin ik ben beginnen ontwikkelen. Bij overdracht naar de klant kreeg ik echter een UnsupportedClassVersionError, waardoor ik te weten ben gekomen dat de officiële java versie die ondersteund wordt 1.6.0_30 is.

Ik heb in de project properties dezelfde javaversie toegevoegd
[afbeelding]
(de -32 staat voor de 32-bit versie)

Desondanks krijg ik nog steeds dezelfde foutmelding bij het overbrengen van de jar

code:

D:\olivia-test_1.52>java -Xmx1024m -Xms256m -jar olivia-test.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: be/dieteren/pvu/frontend/app/MainApplication : 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)
        at be.dieteren.pvu.test.application.Application.startup(Application.java:59)
        at be.dieteren.pvu.test.TestRunner.main(TestRunner.java:38)

51 zou overeenkomen met versie 7, maar bij het exporteren had eclipse toch de 1.6.0_30 moeten nemen?

Java versie op de PC van de klant (Windows XP)

code:

D:\olivia-test_1.52>java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)

Java versie op mijn PC (Windows 7)

code:

C:\Users\msaerens>java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

De default JRE in eclipse staat nog wel op Java 1.7 x64

Wat zie ik nog over het hoofd?

Heb je je Java Compiler juist ingesteld in de Project properties?

LinuX-TUX schreef op vrijdag 20 december 2013 @ 09:50:
[...]

Waar baseer je dit op? Heeft Eclipse een autosense plugin welke deze versie pakt? Hoe ziet je jar build / export eruit?

1 google query levert me overigens het antwoord al en ik zal je een hint geven; "Compliance"

...Oh... Spuit-11

[ Voor 6% gewijzigd door Merethil op 20-12-2013 09:52 ]

[Big Womly]

LinuX-TUX schreef op vrijdag 20 december 2013 @ 09:50:
[...]

Waar baseer je dit op? Heeft Eclipse een autosense plugin welke deze versie pakt? Hoe ziet je jar build / export eruit?

1 google query levert me overigens het antwoord al en ik zal je een hint geven; "Compliance"

Dat 51 overeenkomt met versie 7 heb ik van StackExchange: http://stackoverflow.com/...-major-minor-version-51-0

Hoe controleer ik die autosense plugin?

De Export heb ik gemaakt via Eclipse: file -> Export. Het uiteindelijke resultaat is een Jar met mijn project en alle dependencies in een aparte folder.

Merethil schreef op vrijdag 20 december 2013 @ 09:51:
[...]
Heb je je Java Compiler juist ingesteld in de Project properties?

Ik dacht dat compliance enkel was voor de code layout, maar die staat alvast ook op 1.6

[Merethil]

Big Womly schreef op vrijdag 20 december 2013 @ 10:03:
[...]


Dat 51 overeenkomt met versie 7 heb ik van StackExchange: http://stackoverflow.com/...-major-minor-version-51-0

Hoe controleer ik die autosense plugin?

De Export heb ik gemaakt via Eclipse: file -> Export. Het uiteindelijke resultaat is een Jar met mijn project en alle dependencies in een aparte folder.


[...]


Ik dacht dat compliance enkel was voor de code layout, maar die staat alvast ook op 1.6
[afbeelding]

Refresh en nogmaals exporteren? Autobuild aan? Op die manier zou hij voor 1.6 moeten compileren.

[Hydra]

Je moet wel even een volledige rebuild van all je classfiles forceren. Eclipse doet dit helaas niet automatisch als je je compliance verandert.

Zelf gebruik ik overigens voor releases naar klanten toe altijd ant / maven buildscripts die alles hercompileren om dit soort zaken te voorkomen.

Big Womly schreef op vrijdag 20 december 2013 @ 10:03:
Ik dacht dat compliance enkel was voor de code layout, maar die staat alvast ook op 1.6

Bij deze dan: compiler compliance heeft niks met code layout te maken. Sterker nog; by default is er niks dat echt klaagt over je code formatting e.d. Welke formatter instellingen je gebruikt stel je zelf in in je editor preferences.

[ Voor 42% gewijzigd door Hydra op 20-12-2013 10:10 ]

[Big Womly]

Merethil schreef op vrijdag 20 december 2013 @ 10:06:
[...]


Refresh en nogmaals exporteren? Autobuild aan? Op die manier zou hij voor 1.6 moeten compileren.

Ik had al een paar keer geprobeerd opnieuw te exporteren, maar zonder succes. Zelfs een herstart van de PC hielp niet.

Hydra schreef op vrijdag 20 december 2013 @ 10:09:
Je moet wel even een volledige rebuild van all je classfiles forceren. Eclipse doet dit helaas niet automatisch als je je compliance verandert.

Zelf gebruik ik overigens voor releases naar klanten toe altijd ant / maven buildscripts die alles hercompileren om dit soort zaken te voorkomen.

Dit zal vermoedelijk de oorzaak geweest zijn. Bij het compileren via maven met versie 6, klaagt de compiler over de missing JavaFX classes, wat ik voordien nooit heb gehad. Ik heb met de klant en de developers (die blijkbaar ook Java 7 gebruiken) afgesproken dat we de dan ook voor mijn project dezelfde jre gebruiken die bij de applicatie meegeleverd wordt.

Hydra schreef op vrijdag 20 december 2013 @ 10:09:
[...]


Bij deze dan: compiler compliance heeft niks met code layout te maken. Sterker nog; by default is er niks dat echt klaagt over je code formatting e.d. Welke formatter instellingen je gebruikt stel je zelf in in je editor preferences.

Thanks!

[Hydra]

Dat laatste was een beetje een WTF momentje. Dat Merethil exact dezelfde tekst geschreven heeft

[Merethil]

Hydra schreef op vrijdag 20 december 2013 @ 11:13:
Dat laatste was een beetje een WTF momentje. Dat Merethil exact dezelfde tekst geschreven heeft

Ik heb jouw gedachten gelezen en exact hetzelfde geschreven, maar onzichtbaar voor jou

... Zelfs ik stond even te kijken, kon niet herinneren dat ik dat had geschreven

[Big Womly]

Oeps. Verkeerde quote tag gekopieerd... Ere wie ere toekomt, dus aangepast