Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »

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-1438 - Getting 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

  • No labels