Issue with qualified exports

[Gregg Wonderly]

I agree, this is not very module like if we are building dependencies to export targets.  This is another reason, for me, that this feels wrong.  I am just not sure I understand why we care so deeply for “authorization” to use code when there are so many (nearly countless) ways to exploit the build process output to change that allowance and to make it possible to do anything with the software.  If we can’t actually control this, why is it so necessary to attempt to assert control of something that is literally uncontrollable.

Gregg

> On Jul 20, 2016, at 5:07 PM, Paul Benedict <pbenedict at apache.org> wrote:
> 
> My build is build 9-ea+125-2016-07-08-164610.javare.5260.nc
> 
> 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.
> 
> PS: I don't know if the same thing is checked at runtime, but A should be
> able to be loaded without B, too.
> 
> Cheers,
> Paul