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/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 invo
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 i
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 is an automatic module if the
builder is not
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
This is getting very confusing.
If you use any jar as an automatic module in the "--module-path" (-p) and
add the main class in another jar (in this example jar-b.jar), patch both
and the error happens.
The main class is literally just an empty main method [1].
The error happens even if we use an
On 06/01/2021 19:57, Thiago Henrique Hupner wrote:
Sorry, they are automatic modules.
I'll create a test case.
Also if you can include the output with --show-module-resolution then it
might help track this down quickly (running without any explicit modules
on the module path is, on the surfac
Sorry, they are automatic modules.
I'll create a test case.
Em qua., 6 de jan. de 2021 às 16:56, Alan Bateman
escreveu:
> On 06/01/2021 19:15, Thiago Henrique Hupner wrote:
> > Hi!
> >
> > I've noticed something strange, but I don't know if it is a bug:
> > If we have two jars:
> > module.a wit
On 06/01/2021 19:15, Thiago Henrique Hupner wrote:
Hi!
I've noticed something strange, but I don't know if it is a bug:
If we have two jars:
module.a with the class com.foo.Bar
module.b with the classes com.foo.Bar and com.foo.Main.
Running:
java -p module-a.jar --patch-module=module.a=module-b
Hi!
I've noticed something strange, but I don't know if it is a bug:
If we have two jars:
module.a with the class com.foo.Bar
module.b with the classes com.foo.Bar and com.foo.Main.
Running:
java -p module-a.jar --patch-module=module.a=module-b.jar -m
module.a/com.foo.Main
it throws:
Error: Unab
10 matches
Mail list logo
