#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)
David M. Lloyd
david.lloyd at redhat.com
Wed Feb 22 14:57:23 UTC 2017
One thing that is very unclear to me is, what is the logic behind
decreeing that a module can add "exports" and "uses" on its own but a
LayerController cannot do so for a module in a layer it directly
controls, unless it generates & injects bytecode to do this?
On 02/21/2017 11:05 AM, David M. Lloyd wrote:
> 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
More information about the jpms-spec-experts
mailing list