Return to Answer

To make sure the program runs successfully the module system must be convinced to allow access to the element on which setAccessible was called. All information required for that are contained in the exception message but there are a number of mechanisms to achieve this. Which is the best one depends on the exact scenario that caused it.

1. A library or framework uses reflection to call into a JDK module. In this scenario:

   • {A} is a Java module (prefixed with java. or jdk.)
   • {member} and {package} are parts of the Java API
   • {B} is a library, framework, or application module; often unnamed module @...

2. A reflection-based library/framework like Spring, Hibernate, JAXB, ... reflects over application code to access beans, entities, .... In this scenario:

   • {A} is an application module
   • {member} and {package} are part of the application code
   • {B} is either a framework module or unnamed module @...

If there are too many flags to be added, you might consider using the encapsulation kill switch --permit-illegal-access instead. It will allow all code on the class path to reflect over all named modules. Note that this flag will only work in Java 9!

In this scenario it is likely that you can edit the module that reflection is used to break into. (If not, you're effectively in case 1.) That means that command line flags are not necessary and instead module {A}'s descriptor can be used to open up its internals. There are a variety of choices:

To make sure the program runs successfully the module system must be convinced to allow access to the element on which setAccessible was called. All information required for that is contained in the exception message but there are a number of mechanisms to achieve this. Which is the best one depends on the exact scenario that caused it.

1. A library or framework uses reflection to call into a JDK module. In this scenario:

   • {A} is a Java module (prefixed with java. or jdk.)
   • {member} and {package} are parts of the Java API
   • {B} is a library, framework, or application module; often unnamed module @...

2. A reflection-based library/framework like Spring, Hibernate, JAXB, ... reflects over application code to access beans, entities,... In this scenario:

   • {A} is an application module
   • {member} and {package} are part of the application code
   • {B} is either a framework module or unnamed module @...

If there are too many flags to be added, you might consider using the encapsulation kill switch --permit-illegal-access instead. It will allow all code on the class path to reflect overall named modules. Note that this flag will only work in Java 9!

In this scenario, it is likely that you can edit the module that reflection is used to break into. (If not, you're effectively in case 1.) That means that command-line flags are not necessary and instead module {A}'s descriptor can be used to open up its internals. There are a variety of choices:

See this post for a more detailed discussion and comparison of these approaches.

See this post for a more detailed discussion and comparison of these approaches.

If there are too many flags to be added, you might consider using the encapsulation kill switch --permit-illegal-access instead. It will allow all code on the class path to reflect over all named modules. Note that this flag will only work in Java 9!