#LayerPrimitives

[Stephen Colebourne]

On 17 March 2017 at 16:39, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> It is clear to me that JPMS does contain an API with some flexibility
>> here, but it is hard to judge whether my second expectation is met.
>> This is because the discussion is ledf by OSGI and JBoss Modules
>> migration concerns, rather than by consideration of what a new module
>> system would need. Perhaps these concerns are the same, perhaps not. I
>> would like to see a discussion from the EG about what blocks a
>> theoretical new extended module system built on top of JPMS.
>
> In the green field, all things are possible.
>
> You could create a variety of module systems that behave in a variety of
> ways and yet still adhere to the current JPMS restrictions.  If you're
> willing to discard, rewrite, or retool all existing software, and change
> best practices (even if the current practices are not particularly harmful
> or problematic, or even useful), and derive your acceptable use cases from
> the implementation restrictions (instead of the other way around), you can
> conform to anything and fit in any situation.

I think the evidence is that the JPMS approaches the problem space in
a different way to OSGI/JBossModules, so it is no surprise to find a
clash. These existing module systems still work in classpath mode. It
seems entirely reasonable that they don't work in module mode, since
they represent a clashing view of modularization. Thus, I'm suggesting
that it is right to consider the whole problem space again in terms of
JPMS, not just try to adapt existing projects.

>> it is more important to close out Java 9 and move on.
> Is it though?

Yes. The JPMS can be enhanced in future if necessary. The core team
has spent copious amounts of time on modules, and it is time we got
back to adding features that will benefit productivity, an area where
Java remains weak. Whether modules will be widely adopted remains open
to question, but modularizing the JDK itself will be a step forward,
even if that is the only benefit.

> Will they care that the community process was
> shunned in favor of expedience?

The JCP has tended to work OK for Java EE, but has never been a
suitable mechanism for driving SE. I view it as an artificial box
ticking process for SE - a zombie:
http://blog.joda.org/2011/06/java-se-7-passes-in-zombie-jcp_1590.html

IMO, the issues to resolve are module naming (where all the advice is
that short names will fail the wider community) and automatic modules
(where guessing names is not viable).

Stephen