Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[David M. Lloyd]

On 03/06/2017 02:35 PM, mark.reinhold at oracle.com wrote:
> 2017/3/6 8:08:19 -0800, tjwatson at us.ibm.com:
>> 2017/3/5 18:02:44 -0800, mark.reinhold at oracle.com:
>>> The main problem with the remainder of the proposed methods is that they
>>> vastly increase the space of situations in which the run-time system must
>>> be prepared to update the definitions of modules.  That can, in turn,
>>> limit both the space of potential implementations and the bounds of
>>> practical performance.
>>
>> I obviously don't know the internal details of the java implementation, I
>> can understand your potential concerns.  I do wonder if the performance
>> improvements you speak of can still be done in the vast majority of cases
>> where the controller is not exposed at all.  The controller is only made
>> available when using one of the static defineModule methods on the Layer
>> API.  The static defineModule methods are useful for cases where an
>> existing module system is trying to adhere their modules into JPMS and the
>> additional dynamics are needed by the controller.  But for the typical
>> case where it is JPMS only there is no need for the controller at all, so
>> you should be able to count on things remaining static.
>>
>> I say this knowing it does not simplify the spec or RI for the controller
>> case, but it should allow for you to optimize the common case more at some
>> point.
>
> This approach could allow optimization of the common case but, as you
> note, it would not simplify the specification or its implementations.
> It would, in fact, likely make implementations even more complex since
> optimizing only in some cases, even if they are common, is more complex
> than optimizing all of the time.

I don't think that any argument was made to the contrary by Thomas. 
However I would argue that gains to many (which include but are 
definitely not limited to OSGi implementations and other containers) 
more than offset this additional cost to specialty compiler developers, 
which seems likely to be very small in any event (but would still be 
worthwhile even if it were substantial).

The main objection stated above seems highly theoretical (and easily 
solved), whereas the benefits to existing code are quite real and 
measurable.  Is there evidence to the contrary?

-- 
- DML