Hi, On Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 05/11/2015 09:30, Ali Ebrahimi wrote: > > Hi alan, > So far quite disappointing! > > > In this example then com.baz in layer1 doesn't know anything about > com.bar@2 or other modules that comes into existence in future "child" > layers, at least not statically. > I know that and may be even com.baz not compatible with com.bar@2. So I don't expect sublayers's modules propagated in parent layers. However, in current design we don't involve module version in declaration of dependence and I think that is good decision. So my assumption is: The readability graph for configuration1 is: com.bar@1 reads java.base com.baz reads com.bar@1 The readability graph for configuration2 is: com.bar@2 requires java.base com.foo reads java.base com.foo reads com.baz com.foo reads com.bar@2 > com.baz does read com.bar@1 and as it declares "requires public com.bar" > then I assume com.baz's exported API must have com.bar@1 types in its > method signatories. This will usually be good for other modules in layer1 > or modules in descendants of layer1 that use the com.baz API. > This does not affect modules belong layerx < layer2 so can be happy. If API usage of com.baz in com.foo does not contain any type of com.bar you wouldn't have any issue, otherwise com.foo must live on layer1. > Creating a new layer2 does not change modules in other layers. This means > that creating layer2 will not change com.baz (in layer1) to read com.bar@2 > (in layer2). It is of course possible for com.baz to opt-in and > reflectively to read com.bar@2 but great care is required (static > references in code in com.baz will presumably resolve to types in com.bar@1 > ). > See above. > > > > This scenario would have many usages in future when world would filled > with modules and developers would have to use newer versions of modules to > fix bugs. > What if com.foo compiled against com.bar@2? adding redundant requires com.bar > in com.foo does not help and my app will fail. > > Assuming com.bar@1 and com.bar@2 export the same packages then it should > fail when you attempt to create the Configuration for layer2 as com.foo > cannot read both. > I think this is reasonable that when executing bytecode belong to layer2 (com.foo or com.poo) that request for types of module com.foo we pick from com.bar@2. > In this example then you might consider a new instance of module com.baz > in layer2. That way, layer2 would have com.foo, com.baz and com.bar@2. > If I'm not owner of com.baz or what do for com.baz dependent modules I think we have tree possible choices: 1) pick com.bar@1 for layer1 and layer2 2) pick com.bar@1 for layer1 and com.bar@1 for layer2 3) pick com.bar@2 for layer1 and layer2 I think 2 would be best and flexible choice. Best Regards, Ali Ebrahimi
