what is an illegal reflective access

Question

There are a lot of questions about illegal reflective access in Java 9  I have found plenty of discussion about working around the error messages  but I would love to know what an illegal reflective access actually is  So my question is  What defines an illegal reflective access and what circumstances trigger the warning  I have gathered that it has something to do with the encapsulation principles that were introduced in Java 9  but I can t find an explanation of how it all hangs together  what triggers the warning  and in what scenario

User · Answer

Just look at setAccessible   method used to access private fields and methods   https   docs oracle com javase 8 docs api java lang reflect AccessibleObject html setAccessible-boolean-  https   docs oracle com javase 9 docs api java lang reflect AccessibleObject html setAccessible-boolean-  Now there is a lot more conditions required for this method to work  The only reason it doesn t break almost all of older software is that modules autogenerated from plain JARs are very permissive  open and export everything for everyone

User · Answer

There is an Oracle article I found regarding Java 9 module system     By default  a type in a module is not accessible to other modules unless it   s a public type and you export its package  You expose only the packages you want to expose  With Java 9  this also applies to reflection    As pointed out in https   stackoverflow com a 50251958 134894  the differences between the AccessibleObject setAccessible for JDK8 and JDK9 are instructive  Specifically  JDK9 added     This method may be used by a caller in class C to enable access to a member of declaring class D if any of the following hold          C and D are in the same module    The member is public and D is public in a package that the module containing D exports to at least the module containing C    The member is protected static  D is public in a package that the module containing D exports to at least the module containing C  and C is a subclass of D    D is in a package that the module containing D opens to at least the module containing C  All packages in unnamed and open modules are open to all modules and so this method always succeeds when D is in an unnamed or open module       which highlights the significance of modules and their exports  in Java 9

User · Answer

Apart from an understanding of the accesses amongst modules and their respective packages  I believe the crux of it lies in the Module System Relaxed-strong-encapsulation and I would just cherry-pick the relevant parts of it to try and answer the question   What defines an illegal reflective access and what circumstances trigger the warning   To aid in the migration to Java-9  the strong encapsulation of the modules could be relaxed   An implementation may provide static access  i e  by compiled bytecode   May provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules  i e  to code on the classpath  If the run-time system is invoked in this way  and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed    In such cases  you ve actually ended up making a reflective access which is  quot illegal quot  since in a pure modular world you were not meant to do such accesses   How it all hangs together and what triggers the warning in what scenario   This relaxation of the encapsulation is controlled at runtime by a new launcher option --illegal-access which by default in Java9 equals permit  The permit mode ensures  The first reflective-access operation to any such package causes a warning to be issued  but no warnings are issued after that point  This single warning describes how to enable further warnings  This warning cannot be suppressed   The modes are configurable with values debug message as well as stacktrace for every such access   warn message for each such access   and deny disables such operations    Few things to debug and fix on applications would be -  Run it with --illegal-access deny to get to know about and avoid opening packages from one module to another without a module declaration including such a directive opens  or explicit use of --add-opens VM arg  Static references from compiled code to JDK-internal APIs could be identified using the jdeps tool with the --jdk-internals option   The warning message issued when an illegal reflective-access operation is detected has the following form  WARNING  Illegal reflective access by  PERPETRATOR to  VICTIM    where   PERPETRATOR is the fully-qualified name of the type containing the code that invoked the reflective operation in question plus the code source  i e   JAR-file path   if available  and  VICTIM is a string that describes the member being accessed  including the fully-qualified name of the enclosing type  Questions for such a sample warning    JDK9  An illegal reflective access operation has occurred  org python core PySystemState Last and an important note  while trying to ensure that you do not face such warnings and are future safe  all you need to do is ensure your modules are not making those illegal reflective accesses

User · Answer

If you want to go with the add-open option  here s a command to find which module provides which package - gt  java --list-modules   tr    quot   quot    awk    print  1      xargs -n1 java -d the name of the module will be shown with the   while the name of the packages without it NOTE  tested with JDK 11 IMPORTANT  obviously is better than the provider of the package does not do the illegal access

[java] what is an illegal reflective access

Examples related to java

Examples related to java-9

Examples related to java-module

Examples related to java-platform-module-system