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 <fo...@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" <pbened...@apache.org> > > À: "ZML-OpenJDK-Jigsaw-Developers" <jigsaw-dev@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 >