On 20 March 2017 at 10:47, Andrew Dinn <ad...@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
