From michal at kleczek.org  Fri Dec  3 13:39:03 2021
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Fri, 3 Dec 2021 14:39:03 +0100
Subject: DFS vs BFS search of modules during resolution
Message-ID: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>

Hi All,

During my work on lazy loading of modules I stumbled upon the following possible dependency graph that I would like to handle:

     Y1                  X2

     ^                   ^
     |                   |
(non-transitive)    (non-transitive)
     |                   |
     |                   |

     X1                  Y2

     ^                   ^
     |                   |
     \                   /
      \                 /
       \               /
        \             /
         \           /
          \         /
               Z



Where An means module named A version n.

In other words there is a cycle in dependency _names_ (but not actual ResolvedModules)

Because Configuration uses DFS to find modules in parent configurations it is impossible to create Configuration that would represent such a graph of ResolvedModules.

1. I am trying to understand the reasoning behind DFS selection. While the above situation is not very common (but not that uncommon in environments with multiple modules developed separately) - BFS would handle the need to ?override? some dependencies with proper layering.

2. Is there a way to handle it today?
(Ab)using transitive dependencies might work - I could introduce artificial module M ---(transitive)-->Y2 and make Z require M (so that resolution would replace Y1 found by DFS with Y2 required transitively by M).
Am I missing something?

Thanks,
Michal

From Alan.Bateman at oracle.com  Fri Dec  3 14:33:28 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Dec 2021 14:33:28 +0000
Subject: DFS vs BFS search of modules during resolution
In-Reply-To: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>
References: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>
Message-ID: <82771cd6-2359-2766-0ef2-beea03359c1e@oracle.com>

On 03/12/2021 13:39, Micha? K?eczek wrote:
> Am I missing something?
>
I think you understand it correctly. The notion of multi-parent 
configuration and layers is something that was added for those that were 
focused on interop with other class loader based systems. It was tracked 
as issue #NonHierarchicalLayers [1].

-Alan

[1] 
https://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers



From michal at kleczek.org  Fri Dec  3 14:30:39 2021
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Fri, 3 Dec 2021 15:30:39 +0100
Subject: DFS vs BFS search of modules during resolution
In-Reply-To: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>
References: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>
Message-ID: <69B5EA52-C659-4BF6-BA53-91C7BE1B6836@kleczek.org>


> On 3 Dec 2021, at 14:39, Micha? K?eczek <michal at kleczek.org> wrote:
> 
> 
> 2. Is there a way to handle it today?
> (Ab)using transitive dependencies might work - I could introduce artificial module M ---(transitive)-->Y2 and make Z require M (so that resolution would replace Y1 found by DFS with Y2 required transitively by M).
> Am I missing something?

It seems I missed that resolution algorithm does not replace resolved modules found during DFS with RMs found by processing transitive dependencies (that?s what I hoped :) ) but will report an error.


From michal at kleczek.org  Fri Dec  3 17:23:50 2021
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Fri, 3 Dec 2021 18:23:50 +0100
Subject: DFS vs BFS search of modules during resolution
In-Reply-To: <82771cd6-2359-2766-0ef2-beea03359c1e@oracle.com>
References: <BC4CE65F-9F8E-4BCF-A67E-F4A90419EC7C@kleczek.org>
 <82771cd6-2359-2766-0ef2-beea03359c1e@oracle.com>
Message-ID: <6CAF0F9E-9A70-4A2C-93AC-4470FD73287A@kleczek.org>


> On 3 Dec 2021, at 15:33, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 03/12/2021 13:39, Micha? K?eczek wrote:
>> Am I missing something?
>> 
> I think you understand it correctly. The notion of multi-parent configuration and layers is something that was added for those that were focused on interop with other class loader based systems. It was tracked as issue #NonHierarchicalLayers [1].

I vaguely remember these discussions but cannot find any rationale for DFS vs BFS.

Nevertheless, I was able to solve my problem by replacing original requires with artificially generated random names (to avoid name clashes) and providing (empty) modules having original requires but changed to transitive.

I would say: somewhat convoluted way to achieve control over dependency resolution but workable.

Thanks,

-- Michal