Proposal: #NonHierarchicalLayers

[David M. Lloyd]

On 12/12/2016 05:23 PM, mark.reinhold at oracle.com wrote:
> 2016/12/8 5:46:24 -0800, david.lloyd at redhat.com:
>> On 12/07/2016 05:41 PM, mark.reinhold at oracle.com wrote:
>>> ...
>>>
>>> Could you please describe here, in plain text, what further methods you
>>> think you need?  For IP clarity any material you want this EG to consider
>>> must be posted to this list or to related OpenJDK infrastructure.
>>>
>>> It'd be fine to discuss specific code patches on jigsaw-dev, but again
>>> you'd need to include it directly rather than point to GitHub.  This is
>>> a design issue, though, so it's probably best to discuss it here first.
>>
>> Sure.  I've added the following methods to Layer.Controller:
>>
>> public Controller addPackage(Module source, String pn) { ... }
>> public Controller addOpens(Module source, String pn, Module target) { ... }
>> public Controller addOpensToAll(Module source, String pn) { ... }
>> public Controller addOpensToAllUnnamed(Module source, String pn) { ... }
>> public Controller addExports(Module source, String pn, Module target) {
>> ... }
>> public Controller addExportsToAll(Module source, String pn) { ... }
>> public Controller addExportsToAllUnnamed(Module source, String pn) { ... }
>> public Controller addUses(Module source, Class<?> service) { ... }
>
> Can you explain exactly why you need all these methods?
>
> I can see why you might need the qualified `addExports` method, akin
> to the existing `addOpens` method, if you're doing some form of module
> resolution on your own that's somehow taking named layers, or whatever,
> into account.

Yeah we're assembling the module structure in a multi-stage lazy 
resolution process, thus we don't know exactly what we're opening or 
exporting until after all contents and dependencies are defined (and 
this can change over time).

> The `add{Opens,Exports}ToAll` variants shouldn't be needed since you can
> just include unqualified `open` and `exports` directives in the module
> descriptor that you're going to build anyway.  That has the additional
> benefit of making the exports apparent to the JPMS resolver so that JPMS
> modules can resolve against your modules, whereas invoking these methods
> wouldn't do that.

The problem is that when I first build the module, I don't have all the 
dependency information available, and also some of the dependencies will 
include modules which are not visible to the layer (in fact right now 
I'm putting each module into a separate layer), and some of the 
dependencies are on non-Jigsaw entities which I also can't know initially.

> The `addPackage` method is problematic, in part since it's quite slow
> (at least in HotSpot, where we've optimized for the common case of the
> set of packages in a module never changing).  Can't you compute the set
> of packages in a module at the time you create the descriptor?

Two things prevent this: firstly, we don't have the module contents 
until after we've constructed the module class loader, which requires 
the layer controller in order to process dependencies, so as of now, 
adding contents depends on having the module established.  Secondly, it 
is allowed to add content to a JBoss module after it has been 
established.  The first might be fixable, but I can't think of a way 
around the second.

-- 
- DML