Compilation error due to overloaded method with unavailable parameter type

[Gunnar Morling]

2016-06-01 0:20 GMT+02:00 Alex Buckley <alex.buckley at oracle.com>:

> On 5/31/2016 2:51 PM, Gunnar Morling wrote:
>
>> That said, couldn't the exporting module (here java.desktop) be added
>> implicitly as a dependency when examining a candidate method referring
>> to unavailable types (here BufferedImage) in an automatic module during
>> resolution?
>>
>
> Not sure which resolution you're referring to.


> Module resolution (by the module system) doesn't examine method
> signatures, nor should it.
>
> Overload resolution (by the compiler) doesn't modify the graph of module
> readability set up by 'requires' clauses and -addmods, nor should it.
>

I meant method/overload resolution and indeed have it adding a read edge
when spotting a missing dependency for an automatic module. But I see it's
a slippery path.

>
> Anyway, what if there were two modules observable on the modulepath that
> both export java.awt.image? Or, what if there was one module observable on
> the modulepath that exports java.awt.image but it also exports another
> package that's already exported by a module you read? Trying to infer
> dependencies is fraught with danger which is why the only time we do it is
> for automatic modules, and even then in a limited fashion (previously
> resolved modules only).


Agreed, dependency inference wouldn't be trivial. Still it seems doable for
cases where there are no ambiguities or conflicts. At least the list of
candidates could be logged as proposed by Remi.


>
> Alex
>