#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)

[David M. Lloyd]

Logically a non-goal is not an anti-goal, as I have observed many times 
in the past as well.  Not setting out to do something is not the same 
thing as forbidding it from being done, especially if it is a minimal 
change.

We consider these issue inadequately addressed despite being rejected. 
By JCP procedures, this obligates us to vote "no".  Is there no possible 
compromise?

On 02/21/2017 10:04 AM, mark.reinhold at oracle.com wrote:
> 2017/2/15 14:32:06 -0800, david.lloyd at redhat.com:
>> On 02/15/2017 01:51 PM, mark.reinhold at oracle.com wrote:
>>> ...
>>>
>>> At any rate, if you're not eventually going to use the JPMS resolver to
>>> resolve some JPMS modules against some JBoss modules, in order to obtain
>>> bidirectional interoperation as is now possible with OSGi [2], then why
>>> bother with any of this?
>>
>> I don't want to.  Even with all of our outstanding issues resolved, this
>> end product is not what we'd hoped for and is at best a partial
>> compromise, and in my mind represents far too radical a change in far
>> too short of a time frame.  In many ways it runs flatly counter to what
>> we've learned and accomplished these past several years in our own
>> architecture.
>>
>> The reality though is that if the platform includes a new deployment
>> format with new behaviors, some users will soon expect that this format
>> and its corresponding behaviors to be supported by containers, because
>> it will be viewed by many to be a standard.
>>
>> It's possible that we can support this expectation to an extent simply
>> by adding a separated JPMS container, and that would be a good option
>> for that purpose.  However that leaves our existing deployment model
>> forever deficient because of its relative lack of encapsulation
>> features, and to a lesser extent, reliance on "fake" module diagnostics,
>> to speak nothing of compatibility oddities for users going from one to
>> the other.  If we want to bring our existing deployment model with all
>> its features up to date with the new encapsulation capabilities, we
>> either need to find a way to utilize Jigsaw to do it (which is what I'm
>> trying to accomplish here), or else we need some new API which allows us
>> to establish similar behaviors at a class loader level.
>>
>> Otherwise, you're right: if we can't take advantage of the useful
>> capabilities of JPMS on our own terms, then why would we vote to support
>> what amounts to a competing module architecture and deployment format,
>> which actively undermines alternative systems which can't or won't abide
>> by its restrictions (by the combination of establishing that the JPMS is
>> not a meta-module system, yet also restricting key JVM features to only
>> that system, and ensuring that differing behavioral characteristics
>> (like version numbers or descriptor formats for example) either conform
>> or are relegated to second-class behaviors), and which from our point of
>> view has several critical deficiencies and substantial compatibility
>> problems compared to what we have today?
>>
>> The only reason we would do, for the lack (via the above reasons) of
>> inherently representing a good forward evolution for us, is if it
>> provided a way for us to coexist while also giving us similar
>> capabilities.  Otherwise we frankly shouldn't support such a system at
>> all, and I would hope to persuade others of the same.
>
> 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.
>
> The goal of this JSR is to design a module system approachable by all
> Java developers and suitable for the modularization of the platform
> itself, as stated in the initial JSR submission [1].  It is not a goal
> to design a "meta" module system via which multiple module systems can
> interoperate on an intimate basis, as I have observed at least twice in
> the past [2][3].  That would be a far larger and even more difficult
> project that is clearly beyond the scope of the JSR, despite your
> wishes to the contrary.
>
> In order to achieve this JSR's goal there is no need to expose the
> low-level primitives upon which we have implemented this module system,
> as you request.  Those primitives were not designed for use outside of
> the implementation itself, since designing a meta-module system is not a
> goal.  If that had been a goal then we would have started by studying the
> internals of many existing module systems in order to identify a workable
> set of primitives.  That is not what we have done, however, and without
> having done that I cannot be confident that what we have today is the
> right set of primitives for this non-goal.
>
> 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
> here -- especially not with primitive, low-level operations that could be
> difficult to emulate later on if a better set of primitives is found in
> some future design effort.
>
> 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'm very sorry to see that this is the case.
-- 
- DML