Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

Thomas Watson tjwatson at
Wed Mar 8 21:22:32 UTC 2017

mark.reinhold at wrote on 03/08/2017 02:07:39 PM:
> > No that cannot work without hacks to allow other modules to depend on 
> > unnamed system.bundle module.  The reason is because we have bundles 
> > that make extensive use of org.osgi.framework packages.  These bundles 

> > then also export packages that we want to make available to JPMS 
> > on top.  These bundles have to be loaded in to a named module in order 
> > 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.

That is one way to put it!

I think I would look for other ways to load the extension bundles into 
JPMS.  For example, perhaps I can place them in a new Layer/Module that is 
separate from the framework system.bundle module but maps to the same 
class loader.  This would deviate from how normal fragments are handled in 
the framework, but I think that would be better than hacking in an unnamed 
module.  Care would need to be taken not to claim the extension module 
contained packages already contained by the system.bundle, but that is 
possible to detect.

> >                         It also implies that it will be more difficult 
> > the future to ship an osgi framework implementation jar as a real 
> > 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, 
> 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.

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.

> > FYI, for the most part I see your points about other solutions are 
> > possible to solve the performance issue with private packages.  I'm 
> > pointing out that it was not a necessary concern before Java 9, so we 
> > to be prepared to react.  The private-package scanning issue may well 
> > to be solved outside of JPMS.  Particularly if the internals of 
> > consider the method to be rarely called (if ever) and therefore there 
> > no need for it to be super fast.  But for supporting system.bundle 
> > fragment attachment the addPackage and addExportToAll methods are 
> > The number of calls to these methods to support system.bundle 
> > 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 
> > issue then addPackage must be exceptionally fast and thread safe.
> All of these low-level methods must be thread-safe in any case, no 
> how often they're used, and that's a big part of the inherent 


> > 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 
> > 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. 
> > 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 
> > module instead of the current unnamed module.  Would this be an 
> > solution for addPackage?  We still would need the addExportToAll 
> In implementation terms this would be little different from 
> since the JVM would still have to be prepared to add packages to a named
> module at any time.

I figured as much.

> - Mark


More information about the jpms-spec-experts mailing list