Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[Thomas Watson]

> From: mark.reinhold at oracle.com
> To: Thomas Watson/Austin/IBM at IBMUS
> Cc: jpms-spec-experts at openjdk.java.net
> Date: 03/08/2017 04:31 PM
> Subject: Re: Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)
> 
> 2017/3/8 13:22:32 -0800, tjwatson at us.ibm.com:
> > mark.reinhold at oracle.com wrote on 03/08/2017 02:07:39 PM:
> >> ...
> >> 
> >> I don't think it's unreasonable for an OSGi/JPMS interoperation 
solution
> >> to have to do these things, especially when the alternative is to 
commit
> >> the entire Java SE Platform to otherwise-unnecessary complexity for 
the
> >> long term.
> > 
> > If it was only for this limited case in the support of OSGi framework 
> > extensions then I tend to agree.  I am under the impression that 
others 
> > have more general usecases for these methods.  I am only giving 
feedback 
> > for my usecase to justify the need for the methods.  There may be some 

> > ways around this for OSGi.  I have to investigate to see how bad or 
> > difficult it makes life for us.
> 
> I appreciate all your feedback on OSGi so far.  It'd be helpful to know
> sooner, rather than later, whether you can work through these issues in
> your proof-of-concept implementation.
> 
> - Mark
> 

The approach of taking each dynamic system.bundle fragment that adds 
packages and placing them in their own module can be made to work.  It is 
ugly because it doesn't fit well within the model used by OSGi to resolve 
fragments.  Outside of OSGi and JPMS resolution there will need to be a 
separate sort of resolution that adds the necessary read edges to the 
system.bundle fragment module instance when other modules in the system 
are resolved to the packages provided by the fragment.  In OSGi the read 
edge naturally goes to the host the fragment is attached.  This is 
necessary because a fragment in OSGi can be attached to multiple host 
bundles at the same time.  So the packages get merged into the host and 
provided by the host as separate capabilities from the host's class 
loader.  One difference for system.bundle fragments is that they will ever 
only have one host so we can do this side wiring for the reads to the 
single module representing the fragment without having to worry which 
class loader to use for the fragment module.

When I have adequate time I could see a way to expand this to the general 
case for dynamic attachment of fragments to normal bundles also.  The 
fragments would live in there own Layer so we could generate a new 
module/layer to represent each instance of the fragment that is attached 
to a separate host.  If that was made to work then I would always model 
fragments this way in JPMS even when they are statically resolved with 
their host so that we have a consistent behavior.

There is my feedback.  It is a bit unpleasant from my perspective, but 
possible.  It would would be less unpleasant if we had addPackage and 
addExportToAll which would fit better into our module system. It does seem 
others do have this need for addPackage outside of existing module systems 
[1].

Tom

[1] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011603.html