Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[David M. Lloyd]

On 03/07/2017 10:09 AM, Thomas Watson wrote:
> mark.reinhold at oracle.com wrote on 03/06/2017 05:45:25 PM:
>> So, here's an even higher-level question: Why is it necessary to make
>> the OSGi system bundle appear as a JPMS module in the first place?
>>
>> The scheme I previously suggested [2] maps an OSGi bundle wiring to a
>> JPMS module and layer so that layers of JPMS modules can be resolved
>> against the bundle directly.  If a particular bundle will never be used
>> by a JPMS module, however, then there's no need to handle its wirings in
>> that way, since there's no reason it needs to appear to be a JPMS
> module.
>>
>> In a mixed OSGi/JPMS system would we realistically expect a JPMS module
>> to require the OSGi system bundle, masquerading as a JPMS module, and
> use
>> its exported APIs?  That seems pretty unlikely.  If a component uses an
>> OSGi-specific API then shouldn't it just be written as an actual OSGi
>> bundle in the first place?
>>
>> Could your proof-of-concept implementation be made to work without
>> putting the system bundle in a JPMS layer?  If so then it could continue
>> to implement dynamic framework extensions just as it does today, support
>> the dependence of JPMS modules upon OSGi bundles that export APIs that
>> aren't specific to OSGi, and yet still not require the exposure of the
>> low-level internal methods proposed by #LayerPrimitives.
>
> No that cannot work without hacks to allow other modules to depend on the
> unnamed system.bundle module.  The reason is because we have bundles today
> that make extensive use of org.osgi.framework packages.  These bundles
> then also export packages that we want to make available to JPMS modules
> on top.  These bundles have to be loaded in to a named module in order to
> allow these JPMS modules to require them.  I think it would be an
> unfortunate work around to have to link an edge to an unnamed
> system.bundle module from a bundle module in order to get this
> functionality to work.  It also implies that it will be more difficult in
> the future to ship an osgi framework implementation jar as a real module
> since we must load the implementation of the framework into an unnamed
> module to be fully functional with respect to framework extensions.
>
>
> FYI, for the most part I see your points about other solutions are
> possible to solve the performance issue with private packages.  I'm just
> pointing out that it was not a necessary concern before Java 9, so we need
> to be prepared to react.  The private-package scanning issue may well have
> to be solved outside of JPMS.  Particularly if the internals of addPackage
> consider the method to be rarely called (if ever) and therefore there is
> no need for it to be super fast.  But for supporting system.bundle
> fragment attachment the addPackage and addExportToAll methods are needed.
> The number of calls to these methods to support system.bundle fragments
> should be small and not as concerned with how speedy they are.  On the
> other hand, if addPackage is used to solve the private package scanning
> issue then addPackage must be exceptionally fast and thread safe.
>
> Early on in my POC I had the idea of allowing the Layer creation to be
> able to map a class loader to a to a default module name.  Basically the
> reverse of the existing clf function.  Instead of mapping a module name to
> a class loader this would map a class loader to a default module name. Any
> package that gets defined in a package that is unknown to the modules
> associated with that class loader would get defined as part of the default
> module instead of the current unnamed module.  Would this be an acceptable
> solution for addPackage?  We still would need the addExportToAll though.

This would work for us as well as a replacement for addPackage.

-- 
- DML