Weakness of "requires public"

[Paul Benedict]

Cheers,
Paul

On Tue, Jul 26, 2016 at 4:16 PM, Remi Forax <forax at univ-mlv.fr> wrote:

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

Okay, I accept your scenario for what it is. You created a very nice
example to illustrate your point where everything must be one, but you know
not every project is like this. The whole discussion with Joda Time was
based on having additional functionality from classes which were optional
at runtime. I am raising the issue that transitive dependencies are also
sometimes optional at runtime. Where is the relief for this scenario? It
doesn't exist -- but it should. Just imagine M1 was a 5MB library and B's
only use of A was buried in some code I never trigger. Here the module
author is going to make me lug around 5MB just because. That's a ridiculous
constriction.

Is transitive dependencies a language concern? No.
Is this a build tool concern? Yes.
Is Java a build tool? No.



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

I think this is a very backward. Tools shouldn't be looking at module-info
to calculate anything. That file solely benefits the compiler and runtime.
It is not for configuring a project build. If anything, module-info.java
should be generated and not the other way around.



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

Maven already has transitive dependencies. But I think you looked over my
point that it is Java that cannot exclude the transitives. Maven can. This
is a disconnect. Going back to my theoretical "java.sql" POM, excluding the
transitive dependencies in Maven would have no effect to my compiler and
runtime environment because Jigsaw is trying to be too smart. The
transitives are coming in whether I like it or not.

Cheers,
Paul