Accès illégal au réflecteur par org.springframework.cglib.core.ReflectUtils$1

Question

Mon application CLI JDK 9+181 Spring Boot 2.0.0.BUILD-SNAPSHOT affiche cet avertissement au démarrage :

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils$1 (jar:file:/home/jan/src/fm-cli/target/fm-cli-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-core-5.0.0.RELEASE.jar!/) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of org.springframework.cglib.core.ReflectUtils$1

Il s'agit d'une application console, je dois donc désactiver cet avertissement - comment puis-je faire ?

Note : Cette question pose le problème spécifique de la désactivation de cet avertissement déclenché par Spring ; elle ne fait pas double emploi avec la question suivante JDK9 : Une opération illégale d'accès réfléchi s'est produite. org.python.core.PySystemState qui traite d'un symptôme similaire dans une autre bibliothèque.

Answer 1

Dans le JDK 9+, ajoutez l'option suivante à la JVM pour désactiver l'avertissement lié à l'utilisation de CGLIB par Spring :

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

par exemple :

java --add-opens java.base/java.lang=ALL-UNNAMED -jar target/*.jar

Pas besoin de le signaler, c'est un bogue connu de Spring .

Cela se produit parce que le nouveau système de modules du JDK 9 a détecté un accès illégal qui sera interdit dans un avenir (proche). Vous pouvez en savoir plus sur le système de modules JDK 9 ici .

Mise à jour :

Une correction de ce problème est disponible dans le JDK 9+ avec Spring 5.1+.

Answer 2

Cela m'est également arrivé sur JDK 11 et Spring Boot 2.2.1 (Spring Core 5.2.1).

Ce qui a aidé, c'est de supprimer la dépendance à org.springframework.boot:spring-boot-devtools comme suggéré dans un peu de commentaires à Problème de Spring Framework #22814 .

Answer 3

En complément de la réponse de Jan Nielsen ci-dessus, si vous utilisez Intellij et Spring Boot 2.0.3, qui dépend de Spring core 5.0.7, vous êtes toujours bloqué et n'avez pas de solution.

La sortie pour moi nécessitait deux choses :

• Ajouter le --add-open mentionné par Jan à votre configuration run/debug. Il suffit de modifier la configuration et de regarder sous Environnement / Options VM. Cela permet de faire taire certains des "messages d'accès illégal".

• J'ai également dû ajouter une dépendance à l'application jaxb-api bibliothèque. J'ai eu l'idée grâce au commentaire de ValentinBossi sur ce problème de printemps sur github .

Answer 4

Lorsque vous utilisez l'initialisateur Spring, assurez-vous d'utiliser la dernière version de Spring Boot. Il obtient automatiquement Spring core 5.1 ou supérieur pour vous et vous ne verrez pas l'erreur lorsque vous exécutez le projet.

Vous n'avez donc pas à vous soucier de modifier la configuration de la JVM.

Answer 5

Je suis assis sur ces versions et je vois toujours l'AVERTISSEMENT :

• SpringBoot 2.4.1
• Spring Core FW : 5.3.2 (mon pom parent est celui de Spring Boot, donc cette version est introduite par celui-ci, et non pas définie manuellement par moi)
• Java openjdk version "11.0.9.1" 2020-11-04

La suppression de la dépendance de spring-boot-devtools a également fonctionné pour moi et l'avertissement n'est plus présent au démarrage.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-devtools</artifactId>
  <optional>true</optional>
</dependency>

... En fin de compte, j'utilisais simplement le redémarrage automatique de mon IDE à chaque modification du classpath et je peux m'en passer. Le truc, cependant, c'est que théoriquement nous ne devrions pas nous inquiéter de cela, puisque selon Documentation sur le printemps :

Les outils du développeur sont automatiquement désactivés lors de l'exécution d'une application entièrement packagée. Si votre application est lancée à l'aide de java -jar ou si elle est lancée à l'aide d'un classloader spécial, elle est alors considérée comme une "application de production".

On pourrait donc s'attendre à ce que l'avertissement disparaisse lorsque l'application est lancée en ligne de commande (je ne l'ai pas vérifié).