Concerns mapping existing dynamic module systems to a 1-1 Module->Layer

[David M. Lloyd]

On 03/08/2017 02:08 PM, mark.reinhold at oracle.com wrote:
> Sorry, but I remain unwilling to expose the requested low-level primitive
> operations, for the reasons previously stated.  If the `Layer.Controller`
> API is insufficient as it stands today then we should defer support for
> bidirectional interoperation to a future release.

I can't see Red Hat supporting this JSR without what has been 
categorized as bidirectional OSGi interoperation.  Not just because of 
our so-called "narrow needs" but because overall this is the very 
last-ditch path through a maze of constraints that we have needed to 
traverse in order to work around some critical problems and limitations 
of JPMS itself.  This in turn is going to impact community users whose 
development and execution model does not match whatever highly specific 
case it is that JPMS is trying to model, and it will do so in very real, 
well-understood ways.  And the only other option (not using or 
supporting JPMS) is also a non-option given that it is being positioned 
as a standard.  Essentially you are asking the EG to ratify an unproven, 
clean-room module model *as a standard* when many other proven, 
real-world models exist, to which the proposed model bears little 
resemblance.  I just don't see how that is a reasonable expectation.

This additional complexity that these extra methods is supposed to 
introduce has never been quantified.  The only concrete measure we have 
right now is the dozen-odd lines of code that the proposed patch would 
add.  If we can't concretely quantify this complexity, and it is the 
justification for denying this request, then we cannot reach consensus 
because there's no way to have a rational discussion about it.

-- 
- DML