Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)
tjwatson at us.ibm.com
Tue Mar 7 16:09:59 UTC 2017
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  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
> 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
> 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.
> - Mark
>  http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.3
>  http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-
More information about the jpms-spec-observers