Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[Thomas Watson]

mark.reinhold at oracle.com wrote on 03/08/2017 02:07:39 PM:
> > 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.

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

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

Understood.

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

I figured as much.

> 
> - Mark
> 

Tom