#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)

Tue Feb 21 16:04:42 UTC 2017

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

- Mark

[1] https://www.jcp.org/en/jsr/detail?id=376#2
[2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-February/000019.html
[3] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-July/000377.html
[4] http://openjdk.java.net/projects/jigsaw/spec/reqs/#compatible-java-platform-modularization
[5] http://openjdk.java.net/projects/jigsaw/spec/reqs/#interoperation
[6] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000410.html