new issue: #AllowRequirePackage

[Bernhard Schuhmann]

dear EG members,

reading [1] made me check what happened to peter kriens’ question about module refactoring [2] and it seems it never made it on the issues list. since i couldn't find it elsewhere i hope you don’t mind me proposing it as a new issue:

#AllowRequirePackage - it is currently impossible to split an existing module that is required by others modules without breaking them. Assume module A requires module B which exports packages p and q. In order change the exported packages from B - for instance move package q into a new module C, B must be turned into an aggregator module of two new modules B1, which exports p, and B2 which exports q. B now has to requires public B1 and B2. Instead of existing module B and new module C, we have now three modules B, B1 and B2. Instead module A could just use and imports clause, e.g. imports p, q, and would not be affected if the exported packages of B change. Use imports <package> clause to avoid confusion with requires <module>. 

this should not conflict with any of the requirements for JSR 376. readability of imports <package> would be the same as requires <module> of the module that exports <package>. since only one module is allowed to export a given package, it would always be clear which module to use. if no module on the module path exports the package, or if more than one modules export the package, it’s an error. if both packages p and q would be exported by the same module, imports p, q would obviously be slightly more verbose than requires B. But the freedom to change the exports of B without breaking A IMHO justify the extra verbosity. 

requires <module> could still be supported (with the given limitations regarding refactoring), but imports <package> should be the preferred way to express that a module depends on a package. obviously imports optional <package> would also be required.

pls refer to [1], section Imports/Requires for a more detailed description of the problem.

would be great if this could be considered - if it’s too late for version 9, maybe it’s worth putting on the list for 9.1 or 10?

kind regards

bernhard schuhmann


[1] https://www.infoq.com/articles/java9-osgi-future-modularity <https://www.infoq.com/articles/java9-osgi-future-modularity>
[2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000167.html <http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000167.html>