Weakness of "requires public"

[Remi Forax]

Hi Paul,
suppose you have a module M1 that declare a class A in an exported package,

module M1 {
  exports m1;
}

package m1;
public class A { ... }

now suppose i have a second module M2 that use B as a type of one parameter of a public method

module M2 {
  requires M1;

  exports m2;
}

package m2;
public class B {
  public void m(A a) { ... }
}

now i am in a third module M3 and i want to extends m2.B,
if i write 
module M3 {
  requires M2;
}

package m3;
public class C extends B {
  ...
}

here i have an issue because while i can see B (the module-info requires M2), i can not see m(A) because the module-info doesn't requires m1 which contains A.

So you can modify M3 to requires both M1 and M2, i see no problem with that.
But from the user point of view, a user just want to use an exported class of M2 so a user may want to only require M2, and because a class of an exported package of M1 is part of the public 'interface' of a class of an exported package of M2, M1 is declared as 'require public' in the module-info of M2.

The 'requires public' can be calculated automatically by the IDE (or any other tools that take a look to the classes that are parts of the API) and i'm pretty sure all IDEs will support that sooner than later.

Currently, a Maven POM has no feature likes 'require public', should that feature be introduced or should Maven stick with requiring all modules and it's transitive dependencies that are part of the API, i don't know, but i fail to see why it has an impact on the java platform module spec. It's up to the Maven guys to decide what is better for Maven and the community around. 

regards,
Rémi

----- Mail original -----
> De: "Paul Benedict" <pbenedict at apache.org>
> À: "ZML-OpenJDK-Jigsaw-Developers" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 26 Juillet 2016 20:35:05
> Objet: Weakness of "requires public"

> In a modularized world, I don't see "requires public" delivering the value
> it should.
> 
> Let's take this example:
> module java.sql {
>    requires public java.logging;
>    requires public java.xml;
>    exports java.sql;
>    exports javax.sql;
>    exports javax.transaction.xa;
> }
> 
> Given a theoretical Maven POM representing the "java.sql" module, the POM
> would have to list out the other two modules so that my project compiles
> against all declared modules. It is considered bad practice to compile
> against artifacts I did not declare in my POM. There are three artifacts
> here.
> 
> Would any Maven experts here disagree? I see the positive of "requires
> public" to be negated in build systems. Given what I just found, I do not
> like the idea of public transitive dependencies in the Module Descriptor.
> For developers using build systems, I believe "requires public" should be
> avoided.
> 
> Cheers,
> Paul