JDK9: une opération d'accès réflectif illégale s'est produite. org.python.core.PySystemState

Question

Je suis en train de lancer DMelt programmes (http://jwork.org/dmelt/programme d'aide Java9 (JDK9), et il me donne des erreurs telles que:

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

Comment puis-je résoudre ce problème? J'ai essayé d'ajouter illégale d'accès=permis à la dernière ligne du script "dmelt.sh" (je suis en utilisant bash sous Linux), mais cela n'a pas à résoudre ce problème. Je suis très frustrant avec ce. J'ai été en utilisant ce programme, très souvent, pour très longtemps. Peut-être que je ne devrait jamais passer à JDK9

Answer 1

L' idéal façon de résoudre ce problème serait de

déclaration ce de la les responsables de org.python.de base.PySystemState

et en leur demandant de fixer de tels réfléchissant accès à l'avenir.

---

Si le mode par défaut de permis illégal réfléchissant accès, cependant, alors il est essentiel d'en faire part afin que les gens ne sont pas surpris quand ce n'est plus le mode par défaut dans une version future.

À partir de l'un des fils de discussion sur la liste de diffusion :

--illegal-access=permit

Ce sera la valeur par défaut du mode de JDK 9. Il ouvre le paquet dans chaque explicite module de code dans tous les modules sans nom, c'est à dire, le code sur le chemin de classe, tout comme --permit-illegal-access aujourd'hui.

La première illégal de réflexion accès opération provoque un avertissement émettre, avec --permit-illegal-access, mais aucun avertissement n'est émis après ce point. Ce simple avertissement décrit comment activer d'autres avertissements.

--illegal-access=deny

Cela désactive toutes illégales de réflexion opérations d'accès, sauf pour ceux activés par d'autres options de ligne de commande, comme --add-opens. Cela devient la valeur par défaut mode dans une version future.

Les messages d'avertissement dans n'importe quel mode peut être évité, comme auparavant, par l'utilisation judicieuse de l' --add-exports et --add-opens options.

---

D'où un courant de solution temporaire consiste à utiliser --add-exports que la VM arguments comme indiqué dans les docs :

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

Les mises à jour du module d' export package target-module, indépendamment de module de déclaration. L' target-module peut être sans nom à l'exportation pour tous les modules sans nom.

Cela permettrait à l' target-module d'accéder à tous types de public, en package. Dans le cas où vous souhaitez accéder à la jdk classes internes qui serait encore encapsulé, vous avez pour permettre une réflexion en profondeur à l'aide de l' --add-opens argument:

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

Les mises à jour du module d' open package target-module, quel que soit le module de la déclaration.

Dans votre cas, à l'accès à l' java.io.Console, vous pouvez simplement ajouter en tant que machine virtuelle option -

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

---

Aussi, la note de la même fil que ci-dessus

Lors de l' deny devient le mode par défaut puis-je espérer permit de rester appuyé pour au moins l'une de libération, afin que les développeurs peuvent continuer à migrer leur code. L' permit, warn, et debug modes, au fil du temps, être supprimé, de même que l' --illegal-access option elle-même.

Il est donc préférable de changer la mise en œuvre et de suivre la solution idéale pour elle.

Answer 2

DMelt semble utiliser Jython et cet avertissement est une chose à laquelle les responsables de Jython devront répondre. Il y a un problème à suivre ici: http://bugs.jython.org/issue2582

Answer 3

Le vrai problème est un problème dans le JDK. Il n'y a pas d'accès illégal, mais la méthode JDK trySetAccessible est erronée. J'espère que cela sera corrigé dans une future version du JDK.

essayez de résoudre ci-dessous le lien de réponse

Answer 4

Pour éviter cette erreur, vous devez redéfinir maven-war-plugin en un plus récent. Par exemple:

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

PS fonctionne pour jdk-12

Answer 5

Les développeurs de Jython n’ont aucune solution pratique pour jdk9, selon ce post http://bugs.jython.org/issue2582 . L'explication précédente semble très longue pour comprendre ce qu'il convient de faire. Je veux juste que jdk9 se comporte exactement comme jdk1.4 - 1.8, c'est-à-dire qu'il soit totalement silencieux. La force de la JVM en matière de comparabilité arrière. Je suis tout à fait d'accord d'avoir des options supplémentaires dans JDK9, mais les nouvelles fonctionnalités ne peuvent pas endommager les applications