2
Ich habe meine Anwendung von Java 8 in Java 9 geändert. Die Windows-Systemumgebungsvariable (Pfad) und die JAVA_HOME in Java 9 (jdk-9.0.1) geändert.Das Ausführen von Java 9-Anwendung mit Andockfenster funktioniert nicht - UnsupportedClassVersionError
Beim Ausführen der Anwendung in der IDE (IntelliJ) es gut funktioniert. Es kompiliert auch ohne Probleme mit sbt. Das Ausführen der Anwendung mit Andockfenster funktioniert nicht.
Die Anwendung scheint mit Java 9 erfolgreich kompiliert zu werden, aber Docker versucht es mit Java 8 zu laufen (das ist, was ich von der Ausnahmemeldung lesen).
Befehle:
sbt docker:publish
docker run --rm -p 9000:9000 eu.gcr.io/the-repository-name/the-image-name:1.0
ich die folgende Fehlermeldung erhalten:
Exception in thread "main" java.lang.UnsupportedClassVersionError:
Module has been compiled by a more recent version of the
Java Runtime (class file version 53.0), this version of the
Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at play.api.inject.Modules$.locate(Module.scala:119)
at play.api.inject.guice.GuiceableModule$.loadModules(GuiceInjectorBuilder.scala:276)
at play.api.inject.guice.GuiceApplicationBuilder$.$anonfun$$lessinit$greater$default$9$1(GuiceApplicationBuilder.scala:30)
at play.api.inject.guice.GuiceApplicationBuilder.applicationModule(GuiceApplicationBuilder.scala:102)
at play.api.inject.guice.GuiceBuilder.injector(GuiceInjectorBuilder.scala:185)
at play.api.inject.guice.GuiceApplicationBuilder.build(GuiceApplicationBuilder.scala:137)
at play.api.inject.guice.GuiceApplicationLoader.load(GuiceApplicationLoader.scala:21)
at play.core.server.ProdServerStart$.start(ProdServerStart.scala:51)
at play.core.server.ProdServerStart$.main(ProdServerStart.scala:25)
at play.core.server.ProdServerStart.main(ProdServerStart.scala)
Was muss ich tun müssen, dass Docker verwendet Java 9?
java --version
java 9.0.1
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
docker version
Client:
Version: 17.10.0-ce
API version: 1.33
Go version: go1.8.3
Git commit: f4ffd25
Built: Tue Oct 17 19:00:02 2017
OS/Arch: windows/amd64
Server:
Version: 17.10.0-ce
API version: 1.33 (minimum version 1.12)
Go version: go1.8.3
Git commit: f4ffd25
Built: Tue Oct 17 19:05:23 2017
OS/Arch: linux/amd64
Experimental: true
- Play Version: 2.6.7
- Scala Version 2.12.4
- SBT Version: 1.0.2
- sbt-native-Verpacker: 1.3.1
vielleicht möchten Sie die Version der Bibliotheken nennen. Und das Hauptproblem hier ist eine Kernbibliothek, die stattdessen Java 9-Code als Java 8-Code kompiliert. Related [Kann Dateimodul-info.class in einem Java9-Projekt nicht verarbeiten, führt zu ClassFormatException] (https: // stackoverflow.com/questions/45802981/unfähig zu verarbeiten-Datei-Modul-info-Klasse-innerhalb-a-java9-Projekt-Ergebnisse-in-Klasse) – nullpointer
@nullpointer Kannst du weiter erklären? Die Anwendung läuft in meiner IDE gut, sie kompiliert ohne Probleme mit Java 9 (nicht Java 8). Nur wenn ich es mit Docker veröffentlichen und ausführen, funktioniert es nicht. Der Fehler deutet darauf hin, dass das Projekt mit Java 9 kompiliert wird, aber Docker java 8. – Spen
Ich würde raten, während Sie "veröffentlichen" und "ausführen", könnten Sie einige Core-Bibliothek transitively verwenden, die versuchen, auf die Klassendateien zuzugreifen als wären sie Java 8 Klassen, während sie stattdessen mit Java 9 kompiliert wurden. Für das weitere Debuggen möchten Sie vielleicht die vollständigen Protokolle angeben, detaillierte Schritte während des Veröffentlichens und ausführen, wie in der Frage erwähnt ... Wildste Vermutung ASM war eine Bibliothek, die für einige wenige solcher Instanzen verantwortlich war, die ich in verschiedenen Bibliotheken gesehen habe. – nullpointer