On 7/20/2016 3:07 PM, Paul Benedict wrote:
Currently I am writing a module that another team will consume. Let's just
call these modules A and B. Module A must export its packages to Module B
and B alone.
For reasons beyond my control, I do not have access to Module B. However, I
don't need to consume any types from B or use B in anyway -- just need to
give package visibility to B. So the compiler is stopping me because it
says "error: module not found". Yes, the compiler is right... but it's too
right.
What do you think of loosening the compiler restriction here? I don't see a
reason why the export target must be known at this point.
We start by supposing that compile-time checking is good. Think of how
the compiler checks your 'import' declarations in ordinary .java files.
Even if you do a wildcard import because you're not sure which types
you'll use, you still have the compiler checking that the package
exists. For qualified exports, we assume that if you're friendly enough
with the owner of B to add a qualified export to B, then you're friendly
enough to have a copy of B available. As such, if you write 'exports ...
to V' (yes, V, not B), then we aim to check that V exists. It doesn't,
so you'll get an error, and you'll smack yourself for typing V rather
than B.
A wrinkle in your scenario is that module B requires module A, so B must
be compiled with A present. And, A must be compiled with B present, due
to 'exports ... to B'. There's no circularity in the 'requires' clauses,
but there is effectively a circularity in the module declarations more
broadly. A certain amount of incremental craftsmanship will be necessary
to allow this pair of modules to flower.
PS: I don't know if the same thing is checked at runtime, but A should be
able to be loaded without B, too.
Exports don't drive module resolution, of course, and there's nothing
special for _qualified_ exports in the post-resolution consistency
checks in java.lang.module.Configuration::resolveRequires. So, a
"dangling" qualified export is OK at run time.
Alex
