#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)

[David M. Lloyd]

I want to address a few non-technical matters in this response, separately.

On 02/21/2017 10:04 AM, mark.reinhold at oracle.com wrote:
> I would be disappointed indeed to see you conclude that it is more
> important to protect and promote your home-grown, non-standard module
> system, which appears not to be used much outside of the JBoss/Wildfly
> ecosystem, than it is to support this JSR, which aims to bring
> significant benefits in a standard way to the entire Java ecosystem.

You are presenting a false dichotomy here, that our "home-grown, 
non-standard" module system is not aiming to bring significant benefits 
in a standard way to the entire Java ecosystem.  I contend that we do 
bring significant benefits, and we see adoption not only from our JBoss 
and WildFly ecosystem (which is itself not as inconsequential as you 
might make it seem).  We have a *very* substantial number of real-world 
users that already take advantage of the benefits of modular 
development.  And with that user base comes a great deal of experience 
in the things that work and the things that don't.  I've tried again and 
again to share this experience but it has always been dismissed.

> My caution here is not merely abstract: It is based upon twenty years of
> sometimes-painful experience.  I have too often seen APIs that seemed
> like a good idea at the time but were, in fact, woefully deficient, baked
> into the Java Platform where they fester for ages, cause pain to all who
> use it, and torment those who maintain it.  I will not let that happen

Can you deny that this ivory tower "daddy knows best" rhetoric is 
exactly what has lead to the very baked-in, painfully deficient APIs 
that you refer to?  What about real-world experience?

> At this point we have met the agreed requirements with respect to other
> module systems, namely to ensure that they can run on top of JPMS [4] and
> that they can read JPMS module metadata in order to resolve JPMS modules
> on their own terms, if so desired [5].  We have even extended JPMS to
> enable bidirectional interoperation with OSGi containers [6], a change
> that goes above and beyond the agreed requirements yet is still within
> the spirit of the original JSR.
>
> On this basis I intend to close the following issues without making the
> changes that they suggest.  Those changes add complexity and risk, and
> are not necessary to the achievement of this JSR's stated goal.
>
>   #CyclicDependences
>   #DiscardableModules
>   #LazyConfigurationAndInstantiation
>   #MutableConfigurations
>   #LayerPrimitives

I want to point out that #LayerPrimitives adds very, very little 
complexity and very little risk.  The most extensive version of the 
patch only adds 40-odd lines of quite defensive code, plus JavaDoc. 
Most of the functions of the proposed API are already possible to do, 
but require Layer providers to inject bytecode into their Modules, which 
is unreasonably onerous.  And the last function to add a package to a 
module is the only possible way to enable the ability to supplement 
deployments or generate bytecode into a predictable package (barring 
reserving (many?) such packages ahead of time); it's very simple in and 
of itself and uses functionality and behavior which is already present 
in JPMS.

In what way is this small addition unreasonably complex or risky?
-- 
- DML