Ik ben een beetje in de war.
-
Oracle zegt dat Java 8 zeer compatibel is met Java 7 (achterwaarts). Maar welke mogelijkheden zijn er dat het Java 8-programma succesvol kan worden uitgevoerd op Java 7 (SE/EE)?
-
Als punt één waar was, worden Java 8-applicaties geïmplementeerd en uitgevoerd op een Java 7-serverondersteuning? bijvoorbeeld Tomcat 8 of WildFly?
Antwoord 1, autoriteit 100%
Over het algemeen niet.
De achterwaartse compatibiliteit betekent dat u het Java 7-programma op Java 8 runtime kunt uitvoeren, en niet andersom.
Daar zijn verschillende redenen voor:
-
Bytecode heeft een versiebeheer en JVM controleert of het de versie ondersteunt die het in .class-bestanden vindt.
-
Sommige taalconstructies kunnen niet worden uitgedrukt in eerdere versies van bytecode.
-
Er zijn nieuwe klassen en methoden in nieuwere JRE’s die niet werken met oudere.
Als je het echt, echt wilt (tip: dat doe je niet), kun je de compiler dwingen om de bron als de ene versie van Java te behandelen en bytecode voor een andere uit te zenden, met zoiets als dit:
javac -source 1.8 -target 1.7 MyClass.java
(hetzelfde voor Maven), en compileren tegen JDK7, maar in de praktijk zal het vaker niet werken dan werken. Ik raad je aan dat niet te doen.
EDIT: JDK 8 ondersteunt deze exacte combinatie blijkbaar niet, dus dit zal niet werken. Sommige andere combinaties van versies werken wel.
Er zijn ook programma’s om nieuwere Java-programma’s om te zetten om op oudere JVM’s te werken. Om Java 8 naar 5-7 te converteren, kun je https://github.com/orfjackal/retrolambdaproberen om lager dan 5 te worden , kunt u een van deze kiezen: http://en.wikipedia.org/wiki/Java_backporting_tools
Geen van deze hacks geeft je nieuwe Java 8-klassen en -methoden, inclusief functionele programmeerondersteuning voor collecties, streams, tijd-API, niet-ondertekende API, enzovoort. Dus ik zou zeggen dat het het niet waard is.
Of, aangezien u uw Java 8 JEE-toepassingen op een toepassingsserver wilt uitvoeren, uw hele server op Java 8 draaien, kan het ook werken.
Antwoord 2, autoriteit 16%
Achterwaartse compatibiliteit betekent
Je kunt een lagere configuratie uitvoeren op een hogere configuratie, niet Vice-Versa.
Antwoord 3, autoriteit 10%
Nou, er is het -targetcompiler-optie, waarmee u zich kunt richten op het klassenbestandsformaat van eerdere java-versies. Dit repareert of detecteert echter geen dingen zoals het gebruik van klassen of methoden die zijn geïntroduceerd in JDK API’s na de doelversie.
Antwoord 4, autoriteit 5%
Geen achterwaartse compatibiliteit betekent dat Java7-programma’s onder Java8 zullen draaien, maar het omgekeerde is niet altijdwaar
Je kunt ook Oracle beperkt achterwaartse compatibiliteit
Antwoord 5, autoriteit 4%
Over het algemeen moeten nieuwe versies achterwaartse compatibiliteit bieden, zodat mensen hun werk niet hoeven te verspillen en gemakkelijk kunnen upgraden. Omgekeerd (nieuwere versie draait in oudere versie) is niet noodzakelijk waar, want als je een nieuwe geïmplementeerde functie gebruikt, bestaat die functie duidelijk niet in de vorige versie en zal niet werken.
Met vriendelijke groeten
Antwoord 6
Ik genereerde stubs van WSDL, gecompileerd in java 8 en kon ze implementeren op een server met java 1.6 jvm erop.