Re: DFS vs BFS search of modules during resolution
> On 3 Dec 2021, at 15:33, Alan Bateman 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
Re: DFS vs BFS search of modules during resolution
> On 3 Dec 2021, at 14:39, Michał Kłeczek 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.
Re: DFS vs BFS search of modules during resolution
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
DFS vs BFS search of modules during resolution
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
