Issue with qualified exports

[Alex Buckley]

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.buckley at oracle.com
> <mailto:alex.buckley at 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.
>
>
>
>