#LayerPrimitives aka allowing to add private package at runtime to a module ?

[Remi Forax]

This is currently a point where several of us disagree, here is my opinion on it.

First, we have to all recognize that making something mutable, the content of a module or anything else, makes maintenance, debugging, etc harder than having the same thing non mutable.
So the default choice should to choosing the immutable solution apart if there are good argument.

Also, in term of implementation, making the content of a module mutable can be seen as a cache invalidation issue, and we all know that cache invalidation is a hard problem especially when it's on global states.

With JPMS, a module is now part of the Java language, so it seems weird to make it mutable the same way, a java.lang.Class is not mutable in Java.
But that's not true, in fact a java.lang.Class is mutable in Java, but you can only mutate it using an agent.

I'm pretty sure that if we do not make the content of a module mutable, people will hack the JPMS implementation to make it mutable, because during the development you want to be able to add private package like you want to add new method in an existing class without having to restart the program (think things like JRebel or Vert.x here).

So in my opinion, we should have a mechanism to add private package to a module, there real question is should this mechanism only visible from an agent or should it be also available from the LayerController ?

Aside, there is something that make me uncomfortable in the mails from David or Thomas, I'm maybe wrong, but it seems to me that you are thinking that you will be able to propose to your users to use the JPMS runtime with the current existing modules. I think your are chasing an unicorn/trying to solve a problem nobody care, i maintain several OSGI bundles and i do not want an implementation of OSGI to see them as JPMS modules, not by default because they will not work, the encapsulation model of JPMS is far stricter than the current model (i think it's the same issue with JBoss Module but i've no experience with them). As a user, if i create an OSGI module with a module-info or a bundle manifest that let me specified that this is a JPMS module, then i want it to be seen as a JPMS module but not by default. We have introduced a modulepath which is not a replacement of the classpath exactly for the same reason. So the interropt between OSGI and JPMS or JBoss Module and JPMS should be seen in my opinion with that idea in mind. In that case, supporting fragment that have also a JPMS module can be seen as a corner case, having to iterate over private packages is also not an issue because the existing manifest and the manifest of a JPMS module can be different, having more info, so at runtime the private packages will be available.

Rémi