Hi Robert,

On 10/16/2016 08:52 PM, Robert Scholte wrote:

with the introduction of the module-info something interesting is happening. Up until now the scope of a Java project was limited to the compilation of the classes. In case of Maven the end-user was in full control regarding the classpath and the order of entries. With the order of the dependencies you can control the order of classpath entries. You could add your own dependencies but could also exclude them. The exclude is especially powerful in those cases where library builders have made mistakes (e.g. junit without test-scope) or simply forgot to remove dependencies when refactoring code. The first project poms are often quite clean, but it requires discipline to keep cleaning up your pom, e.g. removing unused dependencies. However, you're not really punished if you don't do this.

With the shift to module-info, suddenly every library-builder gets control. If the module-info of that library "requires A.B", it means that every project using this library MUST have A.B on its module-path. As end-user you cannot exclude A.B, nor can you say "B.A replaces A.B for x.y.z" in case of duplicate classes as allowed on the classpath. In short: the end-users must rely on the discipline of library builders.

This loss of control for the end-user will have huge impact. Maven has a analyze-goal in the maven-dependency-plugin which show both unused declared dependencies and used undeclared dependencies (which means pulled in as transitive dependency, even though the code directly uses it). Almost every time I run this goal on any project it detects dependencies in one of both groups.

To enforce the discipline, the java compiler should IMHO at least check if all required modules are indeed required and if the transitive required modules are indeed transitive. The role of the module-info is way too important to simply allow all content. The scope is not just about the classes anymore; the complete module tree is now locked into the jar. Any mis-configured module-info down the tree can never be fixed by the end-user, which could block the end-user to use the modulepath.

just sharing my concerns,

I think this is a real concern.

Do we need an --exclude-modules (in addition to --add-modules) option on javac, java and jlink commands?

--exclude-modules would be different to --limit-modules. If some module requires module M and there is no module M on the module path or it is not observable because it was not mentioned in the --limit-modules option, then an exception is raised. OTOH if some module X requires module M and module M is mentioned in the --exclude-modules option, then such requires is silently ignored in hope that module X will not actually need types from module M.

Would that satisfy your concerns?

Regards, Peter

Reply via email to