#LayerPrimitives

[Stephen Colebourne]

On 20 March 2017 at 10:47, Andrew Dinn <adinn at redhat.com> wrote:
> Regarding the first point, I have to ask why someone using an
> alternative module system to modularize their code would also want to
> use JPMS to modularize that same code.

The main feature that JPMS offers is the ability to encapsulate
package beyond what is possible today. That is useful behaviour beyond
the bounds of the default implementation of the JPMS. Thus, the intent
of an "alternative module system" I was describing was to use JPMS
modules with module-info in ways beyond that permitted by the default
module-path loader. Fortunately we do have Layers which do appear to
provide quite a lot of flexibility in this area.

> that /my/ perception of requests to support
> more 'dynamic' capabilities in JPMS is that they are based on a
> misguided desire to allow alternative module systems, specifically JBoss
> Modulss and OSGi, to operate hand in glove with JPMS rather than
> interoperate in a coherent and useful manner.

I broadly agree. Some Java 7 libraries work well with lambdas, others
were better with a major rewrite for java 8. The same applies to
existing frameworks and module systems - its OK to need a major
rewrite or redisgn for a major new version of the platform, something
that may lead to very a different approach to today.

Thanks for the additional detailed thoughts, which I found helpful.
Stephen