Accès réfléchi illégal lorsque j'arrête l'application Web Spring Boot avec Tomcat 9 et Java 10
J'essaie Java 10 de développement avec Spring Boot 2 et je rencontre des problèmes.
L'application est une simple webapp basée sur Spring Boot 2. Le lancement de l'application est ok mais quand je l'arrête, je reçois cet avertissement:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.Apache.catalina.loader.WebappClassLoaderBase (file:/C:/Users/CS/.m2/repository/org/Apache/Tomcat/embed/Tomcat-embed-core/9.0.11/Tomcat-embed-core-9.0.11.jar) to field Java.io.ObjectStreamClass$Caches.localDescs
WARNING: Please consider reporting this to the maintainers of org.Apache.catalina.loader.WebappClassLoaderBase
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
Comme vous le voyez, j'ai déjà basculé le serveur Tomcat intégré de la version 8 vers la version 9.0.11 pour être compatible avec le système de modules Java. Et l'application est lancée avec l'option --add-opens Java.base/Java.lang=ALL-UNNAMED
Est-ce que quelqu'un sait pourquoi je reçois ce message?
Pour désactiver ces avertissements, vous aurez besoin des options suivantes dans votre script de démarrage:
--add-opens=Java.base/Java.lang=ALL-UNNAMED
--add-opens=Java.base/Java.io=ALL-UNNAMED
--add-opens=Java.rmi/Sun.rmi.transport=ALL-UNNAMED
comme vous pouvez le voir dans le script de démarrage de Tomcat 9 .
Les correctifs pour les avertissements sont ne devraient pas être résolus de sitôt :
Est-il prévu de les résoudre dans une prochaine version?
Pas pour le moment.
Nous conserverons la compensation explicite aussi longtemps que possible. Une fois qu'il sera définitivement bloqué, nous devrons probablement compter sur le fait que les cartes en question utilisent une référence faible et attendent que le GC efface les références. Cela rendra plus difficile le traçage des fuites de mémoire authentiques, nous devrons donc voir si nous pouvons persuader l'équipe JRE de fournir une sorte d'API de remplacement si/quand nous atteignons ce point.