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> 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. >
