Please see this quote from the JDK11 Release notes:
hotspot/runtime ➜ JEP 181 Nest-Based Access Control
Introduce nests, an access-control context that aligns with the
existing notion of nested types in the Java programming language
(JEP-181: Nest-based access control).
In Java SE 11, the Java Virtual Machine supports the arrangement of
classes and interfaces into a new access control context, called a
nest. Nests allow classes and interfaces that are logically part of
the same code entity, but which are compiled to distinct class files,
to access each other's private members without the need for compilers
to insert accessibility-broadening bridge methods. Nests are a
low-level mechanism of the Java SE Platform; there are no changes to
the access control rules of the Java programming language. The javac
compiler has been updated to use nests when compiling nested classes
and interfaces in Java source code, by generating new class files
attributes that place a top-level class (or interface) and all its
nested classes and interfaces in the same nest. The Java Virtual
Machine has been updated to use these attributes when checking the
accessibility of a private constructor, method, or field, including
via core reflection and the java.lang.invoke.MethodHandles.Lookup API.
Membership in a nest is exposed through the new getNestHost and
getNestMembers methods of java.lang.Class.
As nest membership is recorded in the class file of the top-level
class or interface (the nest host), that class file must be present at
run time to allow the access control checks to be performed. This is
not normally a concern as the top-level class or interface is
typically used directly. In some code where a top-level class or
interface acts only as a holder for nested classes or interfaces, and
is otherwise unused, packaging tools may have elided that class file
from the distribution of a library or application. With nest-based
access control, it is no longer possible to elide the top-level class
or interface if any of the nested classes or interfaces require access
to each other's private members — a NoClassDefFoundError or
ClassNotFoundException will be thrown.
Source
So java changed the rules for how access control is established at runtime, and as a result, Groovy, which appears to be a language that leverages the java platform and its libraries, cannot use reflection to access private members.
Oracle expected this kind of issue with this change, and put in an error message, asking you to report the problem to the makers of the offending plugin.
