On 07/01/2021 13:06, Johannes Kuhn wrote:
:
To be honest - I don't quite understand the bug - but I was able to
reproduce it.
So I did manually retrace the code to see where the difference was
happening, and found the lines above - which was "good enough" for an
explanation.
Resolution involves recursively enumerating the "requires" directives of
a set of root modules (think transitive closure). The root modules are
the module you specify to -m or the modules specified to --add-modules.
Every module requires java.base so it will always be resolved and will
also be in the the boot layer. The bug in the patcher code results in a
root module that does not require java.base and since they are no other
root modules, it means the boot layer doesn't have java.base, oops! But,
the java.base has been partly defined to the VM in very early startup
and normally the creation of the boot layer will complete the
initialization, including setting up exports. The IllegalAccessError
trying to link the super class arises because the exports aren't setup,
meaning java.lang is not exported so no classes outside of java.base can
be linked.
Is there a way to debug the early java initialization? I didn't got
that working, so had to do it by hand.
The debugger needs the VM to be fully initialized before it can debug
Java code. In JVM TI speak this is the "live phase". There are early
phases where tooling and agents can get events and do some operations
during VM startup but it's not enough for a Java debugger.
-Alan.
