Yes, this option has been mentioned in some form.
The good thing about this part is that exports and requires use the same
structure, i.e. the package is the unit shared between 2 modules.
However, this will probably lead to a long list of requirements, so I
understand the choice the name of the bundle of exported packages, being
the module name.
Also keep in mind that one of the fundamental choices made is that the
module descriptor should not have mechanisms for migration path.
That said, one might think that the partial requirements or soft/loose
modules are there also for migration. I would disagree with that. I expect
that some jars will never become a module or will ever be re-released just
for specifying a Automatic-Module-Name attribute, in which case you must
refer to them as auto modules. In such cases you cannot talk about
migration but about the fact that projects will always depend on
unmodularized jars.
One solution was the soft/loose modules proposal which I think is valid
but it all depends on the opinion if this "pattern" will be there just for
migration or not.
Robert
On Fri, 05 May 2017 16:19:38 +0200, Robert J. Saulnier
<robert.j.sauln...@gmail.com> wrote:
I've only somewhat followed this discussion. The following might be
nonsensical or already discussed.
The issue with automatic modules is we don't know what the names of
future
modules will be, but what we do know is what packages we require. So
instead of guessing a module name, we could require package(s) until the
actual module becomes available.
module my.module {
exports ...;
requires ...;
requires package org.junit;
requires package org.junit.rules;
}
So in the above example, it would need to check if a module on the
module-path exports the packages listed, if not, look in the Jar files
for
the packages.
Once Junit modularizes their stuff, we can update our module at our
leisure:
module my.module {
exports ...;
requires ...;
requires <junit module name>;
}
Bob
