reasons to add readability edges when creating layer

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

reasons to add readability edges when creating layer

Michał Zegan
Hi.

Wondering about one thing: What is the example use for addReads method
of ModuleLayer.Controller?
Reflection does not require adding readability edges manually.
Also, if readability edge's target module would not be in a parent layer
or the same layer, seems that the module class loader will not take into
account readability edge changes. Not even sure if it would do this in
case when target module would indeed be in the parent layer.
So, is the only use case the one when I would have a custom class loader
loading by different rules?

Reply | Threaded
Open this post in threaded view
|

Re: reasons to add readability edges when creating layer

Alan Bateman
On 31/12/2017 01:22, Michał Zegan wrote:
> Hi.
>
> Wondering about one thing: What is the example use for addReads method
> of ModuleLayer.Controller?
Code generation or new reflection (java.lang.invoke) would be reasons to
use addReads.

> Reflection does not require adding readability edges manually.
> Also, if readability edge's target module would not be in a parent layer
> or the same layer, seems that the module class loader will not take into
> account readability edge changes. Not even sure if it would do this in
> case when target module would indeed be in the parent layer.
> So, is the only use case the one when I would have a custom class loader
> loading by different rules?
>
If the container is injecting code into a module m1 with references to
m2, and if m1 and m2 are mapped to different loaders, then the container
will need to augment the class loader delegation to support the new read
edge. There isn't any API support for this so it would require the
container to support the module layer with its own class loaders (which
I think is what you are asking).

-Alan




Reply | Threaded
Open this post in threaded view
|

Re: reasons to add readability edges when creating layer

Michał Zegan


W dniu 31.12.2017 o 16:54, Alan Bateman pisze:

> On 31/12/2017 01:22, Michał Zegan wrote:
>> Hi.
>>
>> Wondering about one thing: What is the example use for addReads method
>> of ModuleLayer.Controller?
> Code generation or new reflection (java.lang.invoke) would be reasons to
> use addReads.
>
>> Reflection does not require adding readability edges manually.
>> Also, if readability edge's target module would not be in a parent layer
>> or the same layer, seems that the module class loader will not take into
>> account readability edge changes. Not even sure if it would do this in
>> case when target module would indeed be in the parent layer.
>> So, is the only use case the one when I would have a custom class loader
>> loading by different rules?
>>
> If the container is injecting code into a module m1 with references to
> m2, and if m1 and m2 are mapped to different loaders, then the container
> will need to augment the class loader delegation to support the new read
> edge. There isn't any API support for this so it would require the
> container to support the module layer with its own class loaders (which
> I think is what you are asking).
Is that planned to be added? Or even needed? I wanted to compare jpms
api to jboss-modules and seems to me that jboss-modules does not have
the dependency modification capability at all at the first glance.
Also, would the default module class loader be able to catch new read
edges if the target module was in a parent layer? Not sure how it maps
packages to modules...
>
> -Alan
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: reasons to add readability edges when creating layer

Alan Bateman
On 31/12/2017 16:06, Michał Zegan wrote:
> :
> Is that planned to be added? Or even needed?
I'm not aware of any proposals to add this in the short term.

> I wanted to compare jpms
> api to jboss-modules and seems to me that jboss-modules does not have
> the dependency modification capability at all at the first glance.
> Also, would the default module class loader be able to catch new read
> edges if the target module was in a parent layer? Not sure how it maps
> packages to modules...
Neither the 3 built-in class loaders supporting the boot layer, nor the
class loaders created by the defineModulesWithXXX methods, do not
dynamically augment or change how they delegate.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: reasons to add readability edges when creating layer

David Lloyd
In reply to this post by Michał Zegan
On Sun, Dec 31, 2017 at 10:06 AM, Michał Zegan
<[hidden email]> wrote:
> Is that planned to be added? Or even needed? I wanted to compare jpms
> api to jboss-modules and seems to me that jboss-modules does not have
> the dependency modification capability at all at the first glance.

JBoss Modules does allow modification of dependencies and even
unloading of modules, however it must be done carefully (of course)
with an understanding of how class loading works.

This is not something that you will commonly want or need to do,
because Java class linkage is a one-time operation.  This means that
if your module X depends on module A and a class from X links to a
class form A, and you change the dependency from module A to module B,
X will still have a connection to module A via the already-linked
class.  This is possibly the simplest example of where problems may
begin.

That said, the JBoss OSGi project uses this feature to implement its
relinking capabilities.  It mitigates the possible problems by way of
its service container which helps to minimize the risk of problematic
activity.

--
- DML
Reply | Threaded
Open this post in threaded view
|

Re: reasons to add readability edges when creating layer

Michał Zegan
Seems to me like a good argument for layers as sets of interdependent
modules, as a module using another module prevents unloading the other
module for real, as references still exist to it from the first module.
Although I am not a module expert and trying to learn a bit about those
things.
As for jboss allowing dynamic dependency modification, I just haven't
found that ability, but I have looked mainly at Module, ModuleLoader and
such classes.

W dniu 03.01.2018 o 15:04, David Lloyd pisze:

> On Sun, Dec 31, 2017 at 10:06 AM, Michał Zegan
> <[hidden email]> wrote:
>> Is that planned to be added? Or even needed? I wanted to compare jpms
>> api to jboss-modules and seems to me that jboss-modules does not have
>> the dependency modification capability at all at the first glance.
>
> JBoss Modules does allow modification of dependencies and even
> unloading of modules, however it must be done carefully (of course)
> with an understanding of how class loading works.
>
> This is not something that you will commonly want or need to do,
> because Java class linkage is a one-time operation.  This means that
> if your module X depends on module A and a class from X links to a
> class form A, and you change the dependency from module A to module B,
> X will still have a connection to module A via the already-linked
> class.  This is possibly the simplest example of where problems may
> begin.
>
> That said, the JBoss OSGi project uses this feature to implement its
> relinking capabilities.  It mitigates the possible problems by way of
> its service container which helps to minimize the risk of problematic
> activity.
>