Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[mark.reinhold at oracle.com]

2017/3/10 9:37:41 -0800, tjwatson at us.ibm.com:
> 2017/3/8 14:31:45 -0800, mark.reinhold at oracle.com:
>> 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.
> 
> 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.

Good -- thanks for the confirmation.

>            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].

[1] suggests that the `java.lang.instrument.Instrumentation` interface
should allow packages to be added to an existing module at run time.
That interface is intended only to support the concurrent instrumentation
of existing code, which does not require that capability; it was never
meant to support the style of fine-grained incremental development
assumed in [1].  Comprehensive platform-level support for that might be
desirable one day, but it's well beyond the scope of this JSR.

- Mark


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