Since A does not require B, you are quite right that the compiler
doesn't need B to compile A per se. It's solely the qualified export to
B that drives the compiler to demand B when compiling A's module
declaration. (I believe that javac should be disinterested in B when
compiling A's type declarations.)
By all means, raise an issue on jpms-spec-comments about how a qualified
export induces a compile-time circularity, being sure to note that
taking a more relaxed view means passing through garbage qualified exports.
Alex
On 7/20/2016 4:22 PM, Paul Benedict wrote:
Alex, I must respectfully disagree with your analogy. We both agree that
it is good for the compiler to check an "import" statement. I imagine we
would also both agree that checking "requires" is good too. I would
argue what makes this good is because the developer has the intention of
locating and consuming a resource -- package or module, respectively.
Even with a wildcard import statement, I am explicitly asking to consume
the contents of a package (whatever the contents); so if the package
isn't there, my intention cannot be met.
However, in my scenario here, I have no need to consume. Module A is not
consuming anything from Module B. All I want to do is issue a directive
for Module B at runtime, if B is even available at runtime. So I don't
really think the analogy you gave me applies.
Now, I could write a stub project for B and install it somewhere, but
that is kind of silly, don't you think? Why make me go through these
hoops? The compiler isn't providing any value here with this check. The
compiler doesn't need B to be statically accessible to prove anything
about exporting a package, does it? If it does, can you let me know why
it needs this proof?
Cheers,
Paul
On Wed, Jul 20, 2016 at 6:00 PM, Alex Buckley <alex.buck...@oracle.com
<mailto:alex.buck...@oracle.com>> wrote:
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.
