> Hopefully this will be rare. Subclassing creates a very tightly coupled dependency and it really shouldn’t be done across module boundaries.
While I agree that subclassing is more tightly coupled than say ECS - most subclasses are of 3rd party classes...? Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 26, 2016 at 2:54 PM, Neil Bartlett <njbartl...@gmail.com> wrote: > If you have client code that depends on Animal and calls the eat(Organism) > method, then your code has a direct dependency on Organism. Now you have a > choice between: > > 1. explicitly declaring requirements for all the types that you actually > use (i.e. Animal and Organism) > 2. explicitly declaring requirements for a subset of the types you > actually use (Animal) but not others (Organism). > > You are essentially arguing for the latter, and while this is clearly less > typing I’m not sure that it’s any simpler. > > What happens if the module that exposes Animal is refactored and no longer > uses “require public” for Organism? In the former case your module > continues to work but in the latter it stops working. > > You also raise the question of inheritance. Using a type that extends from > Animal has always required visibility of the full type hierarchy, so this > means you should depend on the base class module also. Hopefully this will > be rare. Subclassing creates a very tightly coupled dependency and it > really shouldn’t be done across module boundaries. > > Regards, > Neil > > > > > On 26 Jul 2016, at 22:40, Malachi de Ælfweald <malac...@gmail.com> > wrote: > > > > 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 > >> > >
