Weakness of "requires public"

[Malachi de Ælfweald]

I admit I came late to the discussion, so I am probably missing something
obvious.

To try to better understand the discussion, I replaced the abritrary
A/B/C/M1/M2/M3 with concrete names...

package world;
public class Organism{...}

package fauna;
public class Animal {
    public void eat(Organism organism){...}
}

package canine;
public class Dog extends Animal {
}

So looking at this... If I were to depend on the canine package/module, I
would assume that eat(Organism) would still work which would mean that both
fauna and world were included as well.
I agree that this seems more like a build tool issue - but if I were to be
writing the canine module, I should not be expected to know/maintain what
is inside the fauna black box.  That's done by someone else.




Malachi de Ælfweald
http://www.google.com/profiles/malachid

On Tue, Jul 26, 2016 at 2: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.
>
> 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
>