new issue: #AllowRequirePackage

[Bernhard Schuhmann]

dear EG members,

let me add another example: module A requires modules B and C. module B exports 
package p and module C exports package q. if package q would be moved into 
module B during a refactoring, module C would be obsolete. however, it must be 
kept (empty?) to satisfy the requires dependence of module A. if module A would 
imports p, q, it would not be affected by the refactoring of modules B and C at all.

while platform modules might not be expected to change once they’re designed 
(And hence requires <module> is less of a problem), application level modules 
might change over time. maybe the modules were designed too fine-grained at 
the beginning - or too coarse-grained as in my example below…

kind regards

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>