Require optional linking error

[Alan Bateman]

On 09/08/2012 13:00, Paul Sandoz wrote:
> Hi,
>
> If i have the following modules:
>
> module x at 1.0 {
>    requires y at 2.0;
> }
> module y at 2.0 {
> }
> module z at 1.0 {
>    requires optional y at 1.0;
>    requires x;
> }
>
> and javac processes module z first, then the resolver passes and module z at 1.0 will get linked to y at 2.0:
>
>       [exec]   context +y
>       [exec]     module y at 2.0
>       [exec]       view y at 2.0
>       [exec]     local  [y at 2.0]
>       [exec]     remote [+jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata+sun.resources]
> ...
>       [exec]   context +z
>       [exec]     module z at 1.0
>       [exec]       view z at 1.0
>       [exec]     local  [z at 1.0]
>       [exec]     remote [+jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata+sun.resources, +y, +x]
> ...
>       [exec]   context +x
>       [exec]     module x at 1.0
>       [exec]       view x at 1.0
>       [exec]     local  [x at 1.0]
>       [exec]     remote [+jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata+sun.resources, +y]
>
> This is similar to the permits issues that i previously highlighted.
>
> It's easy to catch this error (and the one for permits) if optional dependency resolution is augmented on to result of the mandatory dependency resolution.
>
> Paul.
There are anomalies with the current implementation that arise due to 
order. In this case I think it should be an error due to the conflict 
(which I think is what you are saying too). One could argue that it 
could succeed with z just not linked to y but that might be problematic 
if something in z were to meet up with a type from y at runtime.

-Alan.