In fact, the JVMTI Specification states[1]:
> As an aid to agents that deploy supporting classes on the search path
of the bootstrap class loader, or the search path of the class loader
that loads the main class, the Java virtual machine arranges for the
module of classes transformed by the Cl
On 07-Jan-21 20:04, Alan Bateman wrote> [...] 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 st
On 07-Jan-21 11:01, Alan Bateman wrote:
On 06/01/2021 23:49, Johannes Kuhn wrote:
Indeed a bug.
Happens under the following conditions:
* Patched module is an automatic module
* Patch adds one or more additional packages to the module.
:
Proposed fix:
* Change requires to not check if it
Indeed a bug.
Happens under the following conditions:
* Patched module is an automatic module
* Patch adds one or more additional packages to the module.
Cause are the following lines:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/module/ModulePatcher.java#L
On 10-Dec-20 8:59, Alan Bateman wrote:
On 09/12/2020 22:45, Johannes Kuhn wrote:
Hope I got the right mailing list, otherwise please direct me there.
Module.addOpens currently doesn't produce an illegal access warning
if the target package has only be opened for illegal access.
The M
Hope I got the right mailing list, otherwise please direct me there.
Module.addOpens currently doesn't produce an illegal access warning if
the target package has only be opened for illegal access.
Reproducer:
import java.lang.reflect.Method;
import java.net.URL;
import java.net.U
