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.
