Thank you Alex. Sounds like good advice. I'll raise it over there. Thanks for chatting with me about it.
Cheers, Paul On Wed, Jul 20, 2016 at 6:37 PM, Alex Buckley <alex.buck...@oracle.com> wrote: > 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. >> >> >> >> >>
