Discussion: #MutableConfigurations, #LazyConfigurationAndInstantiation, #CyclicDependences, & #DiscardableModules

[David M. Lloyd]

On 11/18/2016 10:30 AM, mark.reinhold at oracle.com wrote:
> References:
>
>   http://openjdk.java.net/projects/jigsaw/spec/issues/#MutableConfigurations
>   http://openjdk.java.net/projects/jigsaw/spec/issues/#LazyConfigurationAndInstantiation
>   http://openjdk.java.net/projects/jigsaw/spec/issues/#CyclicDependences
>   http://openjdk.java.net/projects/jigsaw/spec/issues/#DiscardableModules
>
> In light of Thomas Watson's initial attempt to achieve bidirectional
> interoperation between OSGi and JPMS [1], my subsequent suggestion that
> this can be done indirectly with the present design by modeling a dynamic
> module as a sequence of JPMS modules over time [2] if given a solution to
> #NonHierarchicalLayers [3], and then Watson's validation of that approach
> [4], it appears that we no longer have any need to address the above four
> issues, at least as far as OSGi is concerned.
>
> David: Is this approach workable for JBoss Modules as well?  If so then
> I'd like to close these issues out; if not then I'd like to understand
> if there are additional, smaller changes that would make this approach
> acceptable while avoiding the complexity of complete solutions to these
> issues.

Partially, but not completely...  In particular I am worried about 
#CyclicDependences (and honestly I'm not entirely convinced that OSGi 
works completely correctly without it either, for the same reasons that 
we would need it; I think maybe Mr. Watson's implementation can skate by 
on an illusion of circularity but I can't see how it would work for us). 
  I am concerned that it will not be realistic to prune every circular 
reference in any potential module graph, even using service loaders; 
IIRC I had to add circularity support to JBoss Modules almost 
immediately due to cases that could not be practically supported in any 
other way, and I don't expect that to have changed now.  This is 
especially true where compile time dependencies differ from run time 
dependencies, which I think will be fairly common, due to the basic 
reality (upon which I have expounded in the past) that the minimum 
practical de facto dependency contract of a given artifact is defined by 
its ABI, not by its identity or other content.  Some module circuits are 
fairly long and it's not obvious how they could be resolved.

Also I am having a hard time figuring out how to adapt our dependency 
API to the #NonHierarchicalLayers proposal.  I'll post a separate reply 
to that mail though.

Beyond that, I would need to do more testing to see what blows up, but 
the other portions seem acceptable and practical.

-- 
- DML