Setting up introspection

JRFork provides tools to send and receive objects on different jvms. This functionality requires sending classes that are missing on recipient jvm. This can be achieved in three major ways:

1. Get loaded classes via instrumentation. Good for basic info, to limit amount of data sent slightly
2. Get classes used in bytecode of object class. This covers most of classes needed, however due to inheritance and generics it does not get all classes required for correct object execution.
3. Inspect objects stored in fields recursively, using reflection API. This covers a hole left by previous method, but comes at a cost.

Since Java 9 introspection became seriously limited with introduction of modules. Now method 3 can face problems accessing fields of classes of non-open modules. E.g. introspection of ArrayList by looking in its fields will fail, since java.base/java.lang is a closed package. However packages still can be imported open with --add-open vm option.

Now it`s necessary to figure out which packages need to be opened for correct work of this program, and which can remain closed.

ObjectIntrospection class provides tools to log this behaviour (check ObjectInstrospection.InaccessibleModulePolicy enum), and approaches to fine-tune access. For development and debugging this log options can be set to visible and even produce exceptions, that can help developer understand which packages should be imported open, and which can be left impenetrable for reflection to maintain security. After program is set up correctly one can disable this information all together, effectively setting a barrier after which this object introspection is no longer required.