Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[mark.reinhold at oracle.com]

2017/3/7 8:09:59 -0800, tjwatson at us.ibm.com:
> 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?
>> 
>> ...
>> 
>> 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.

Okay, so it's possible, but it's unpleasant.

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

More difficult, perhaps, but still possible.  An OSGi framework could be
embedded in a JPMS module as a JAR-file resource that its launcher, which
is regular code in that JPMS module, loads directly into the unnamed
module of an appropriate class loader.

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.

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

All of these low-level methods must be thread-safe in any case, no matter
how often they're used, and that's a big part of the inherent complexity.

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

In implementation terms this would be little different from `addPackage`,
since the JVM would still have to be prepared to add packages to a named
module at any time.

- Mark