On 14.04.20 19:38, Alex Buckley wrote:
[...]
It's fine for
Library1 to require SharedApi, and for Library2 to require
SharedApiImpl, but if the exported packages overlap, then it's not fine
for Project to require, indirectly, both SharedApi (via Library1) and
SharedApiImpl (via Library2). That is
On 14/04/2020 20:48, Alex Sviridov wrote:
Hello everybody,
I try to understand how classloading works when there are multiple child layers
and have a problem.
Let's consider the following situation. There are three layers.
BootLayer (moduleA)
|
|___Child1(moduleB)
Hi Alan,
Thank you very much for such detailed answer! Only one note — is the following
paragraph right?
«When Child2 is created it will create L2 and map moduleC to L2. When
code in moduleC tried to resolve a reference to a class in its own
module then it will be loaded by L1 (POINT X) (no de
On 15/04/2020 12:45, Alex Sviridov wrote:
Hi Alan,
Thank you very much for such detailed answer! Only one note — is the following
paragraph right?
«When Child2 is created it will create L2 and map moduleC to L2. When
code in moduleC tried to resolve a reference to a class in its own
module
On 4/15/2020 12:00 AM, Jochen Theodorou wrote:
On 14.04.20 19:38, Alex Buckley wrote:
[...]
It's fine for
Library1 to require SharedApi, and for Library2 to require
SharedApiImpl, but if the exported packages overlap, then it's not fine
for Project to require, indirectly, both SharedApi (via Lib
- Mail original -
> De: "Jochen Theodorou"
> À: "jigsaw-dev"
> Envoyé: Mercredi 15 Avril 2020 08:55:00
> Objet: Re: excluding transitive module
> On 14.04.20 20:20, Remi Forax wrote:
>> Hi Jochen,
>> JPMS has no notion of of API and implementation of the same jar. It's a
>> concept
>> o
Hi Claes,
This is very good optimization. I have a few nit picks:
[1] I think the following is unnecessary. The original
Java_java_lang_Module_defineModule0 and GetInternalPackageName function
did not perform null check or type check. I think this should be changed
to an assert.
The array c
