You are here probably because you're wondering what do the following warnings logged by rnode mean.
WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:/usr/share/rnode/lib/com.google.protobuf.protobuf-java-3.5.1.jar) to field java.nio.Buffer.address WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil 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
Java 9 introduced modularity — aka Project Jigsaw — for stronger encapsulation (hiding of library internals and exposing only intended APIs). The goal is to make library authors not worry about potential impact of internal refactorings on users of internal APIs. This project makes it way more harder to depend on library internals. It also makes library organization somewhat elegant. For instance, transitive dependencies are not seen by dependency siblings.
Sadly, the mechanism hasn't gained much traction yet, and most of the libraries that depend on Java's JDK internal APIs, in most cases on sun.misc.Unsafe
class for performance reasons, haven't migrated to new APIs (if there are any). So far JVM just issues warnings on accesses to non-exported APIs one of which you see above. In case of RChain, most, if not all, of these accesses occur in 3rd party libraries, which makes it really hard to properly eliminate these warnings. It would mean to record every such illegal access warning, check if the library that caused it has a new version that fixed it, and if not, fix the library or at least submit a bug report.
There's no straightforward way to silence these warnings. The JVM command line parameter that controls it is --illegal-access=<policy>
(see https://docs.oracle.com/en/java/javase/11/tools/java.html), it is set to permit
by default — warning on first illegal access only per library and class — and that is the most liberal option. We can use --add-opens
though. It can entirely open one module — export all its classes — to another. The illegal accesses here
-
CORE-1438Getting issue details...
STATUS
are to internal JDK APIs. We could then open JDK to problematic modules. Most, if not all, of libraries we use don't support modularity and I'm not sure how the new JVM treats old world where there's just bunch of JARs on CLASSPATH. There was some proposal on Automatic Modules that would turn JARs into modules, but I'm not sure how the development has evolved.
For details see