it-swarm.com.de

JDK9: Ein ungültiger reflektierender Zugriffsvorgang ist aufgetreten. org.python.core.PySystemState

Ich versuche, DMelt-Programme ( http://jwork.org/dmelt/ ) mit Java9 (JDK9) auszuführen, und es werden folgende Fehler angezeigt:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.python.core.PySystemState (file:/dmelt/jehep/lib/jython/jython.jar) to method Java.io.Console.encoding()
WARNING: Please consider reporting this to the maintainers of org.python.core.PySystemState
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Wie kann ich es reparieren? Ich habe versucht, –illegal-access = allow in die letzte Zeile des Skripts "dmelt.sh" (ich verwende bash in Linux) einzufügen, konnte dieses Problem jedoch nicht lösen. Ich bin sehr frustrierend. Ich habe dieses Programm sehr oft und sehr lange benutzt. Vielleicht sollte ich niemals zu JDK9 wechseln

37
IraS

Der ideale Weg, dies zu lösen, wäre zu 

dies den Betreuern von org.python.core.PySystemState melden

und sie bitten, diesen reflektierenden Zugang in Zukunft zu korrigieren.


Wenn der Standardmodus jedoch einen illegalen spiegelnden Zugriff zulässt, dann Es ist wichtig, dies bekannt zu machen, damit die Leute nicht überrascht sind, wenn Dies ist in einer zukünftigen Version nicht mehr der Standardmodus.

Von einem der Threads auf der Mailingliste :

--illegal-access=permit

Dies ist der Modus default für JDK 9. Es öffnet sich jedes Paket in Jedes explizite Modul muss in allen nicht benannten Modulen codiert werden, d. h. Code auf der Klassenpfad, genau wie --permit-illegal-access heute.

Die erste unzulässige reflektierende Zugriffsoperation bewirkt, dass eine Warnung .__ ist. wie bei --permit-illegal-access ausgegeben, es werden jedoch keine Warnungen ausgegeben nach diesem Punkt. Diese einzige Warnung beschreibt das Aktivieren von weitere Warnungen.

--illegal-access=deny

Dies deaktiviert alle illegalen reflektierenden Zugriffsvorgänge mit Ausnahme von die von anderen Befehlszeilenoptionen aktiviert werden, z. B. --add-opens. Dieses wird in einer zukünftigen Version zum Standardmodus.

Warnmeldungen in jedem Modus können wie zuvor durch die sinnvolle Verwendung der Optionen --add-exports und --add-opens vermieden werden.


Daher ist eine derzeit verfügbare temporäre Lösung die Verwendung von --add-exports als VM - Argumente, wie in docs erwähnt:

--add-exports module/package=target-module(,target-module)*

Aktualisiert das Modul zu export zu target-module, unabhängig von Moduldeklaration. Der target-module kann aus unbenannt bestehen, der nach .__ exportiert werden soll. alle nicht benannten Module.

Auf diese Weise kann target-module auf alle öffentlichen Typen in package zugreifen. Wenn Sie auf die jdk-internen Klassen zugreifen möchten, die noch eingekapselt wären, müssen Sie ein tiefe Reflexion mit dem --add-opens-Argument zulassen:

--add-opens module/package=target-module(,target-module)*

Aktualisiert das Modul mit dem open -Paket unabhängig vom Modul .__ auf target-module. Erklärung.

Wenn Sie aktuell auf Java.io.Console zugreifen, können Sie dies einfach als Option VM hinzufügen.

--add-opens Java.base/Java.io=ALL-UNNAMED

Beachten Sie auch den gleichen Thread wie oben

Wenn deny zum Standardmodus wird, erwarte ich, dass permit für mindestens ein Release unterstützt wird, sodass Entwickler ihren Code weiterhin migrieren können. Die Modi permit, warn und debug werden mit der Zeit entfernt die --illegal-access-Option selbst.

Daher ist es besser, die Implementierung zu ändern und der idealen Lösung zu folgen.

28
nullpointer

DMelt scheint Jython zu verwenden, und diese Warnung wird von den Jython-Betreuern angesprochen. Es gibt ein Problem, das hier nachverfolgt wird: http://bugs.jython.org/issue2582

6
Alan Bateman

Um diesen Fehler zu vermeiden, müssen Sie maven-war-plugin Neu definieren. Zum Beispiel:

<plugins>
    . . .
    <plugin>
        <groupId>org.Apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>3.2.2</version>
    </plugin>
</plugins>

P.S. Funktioniert für jdk-12

2
Drakonoved

Ein echtes Problem ist ein Problem im JDK. Es gibt eigentlich keinen illegalen Zugriff, aber die JDK-Methode trySetAccessible verhält sich falsch. Dies wird hoffentlich in einer zukünftigen JDK-Version behoben.

löse die Antwort unten. link

1
Thilina Sampath

Jython-Entwickler haben gemäß diesem Beitrag http://bugs.jython.org/issue2582 ..__ keine praktische Lösung für jdk9. Die vorherige Erklärung scheint sehr lang zu sein, um herauszufinden, was zu tun ist. Ich möchte nur, dass sich jdk9 genau wie jdk1.4 - 1.8 verhält, also völlig still ist. Die Stärke der JVM in der Rückwärtsvergleichbarkeit. Ich bin vollkommen in Ordnung, zusätzliche Optionen in JDK9 zu haben, aber neue Funktionen können Anwendungen nicht beeinträchtigen

1
IraS

Möglicherweise funktioniert das folgende Update auch für Java 9:

In meinem Fall war die Java-Open-JDK-Version 10.0.2 und es wurde derselbe Fehler angezeigt (Eine illegale reflektierende Zugriffsoperation ist aufgetreten). Ich habe Maven auf Version 3.6.0 unter Linux aktualisiert, und das Problem war weg. 

0
Rob Lassche