Question on Implied readability

[Ali Ebrahimi]

Hi,
This patch works for me:

diff --git a/src/java.base/share/classes/java/lang/module/Resolver.java
b/src/java.base/share/classes/java/lang/module/Resolver.java
--- a/src/java.base/share/classes/java/lang/module/Resolver.java
+++ b/src/java.base/share/classes/java/lang/module/Resolver.java
@@ -263,6 +263,34 @@

                 // already defined to the runtime
                 if (mref == null && layer.findModule(dn).isPresent()) {
+                    //Implied readability wrt to layers
+                    ModuleDescriptor parentLayerModuleDescriptor =
layer.findModule(dn).get().getDescriptor();
+                    for (ModuleDescriptor.Requires
parentLayerModuleRequires : parentLayerModuleDescriptor.requires()) {
+
 if(parentLayerModuleRequires.modifiers().contains(Requires.Modifier.PUBLIC))
+                        {
+                            String dn2 = parentLayerModuleRequires.name();
+                            //Search for implicitly required module in
current layer
+                            ModuleReference mref2 = find(beforeFinder,
dn2);
+                            if(mref2 != null){//module dn2 overrided in
current layer
+                                // check if module descriptor has already
been seen
+                                ModuleDescriptor other2 =
mref2.descriptor();
+                                if (!selected.contains(other2) &&
!newlySelected.contains(other2)) {
+                                    if (nameToReference.put(dn2, mref2) ==
null) {
+                                        if (TRACE) {
+                                            trace("Module %s located,
required by %s",
+                                                    dn2, descriptor.name
());
+                                            if
(mref2.location().isPresent())
+                                                trace("  (%s)",
mref2.location().get());
+                                        }
+                                    }
+
+                                    newlySelected.add(other2);
+
+                                    q.offer(other2);
+                                }
+                            }
+                        }
+                    }
                     trace("Module %s found in parent Layer", dn);
                     continue;
                 }
@@ -508,10 +536,14 @@
                     g2.put(descriptor, requiresPublic);
                     for (Requires d: descriptor.requires()) {
                         String dn = d.name();
-                        if (nameToDescriptor.get(dn) == null
-                            &&
d.modifiers().contains(Requires.Modifier.PUBLIC))
+                        if
(d.modifiers().contains(Requires.Modifier.PUBLIC))
                         {
-                            ModuleReference mref = findInLayer(l, dn);
+                            ModuleReference mref;
+                            if(nameToDescriptor.get(dn)== null){
+                                mref = findInLayer(l, dn);
+                            }else {
+                                mref = find(beforeFinder,dn);
+                            }
                             if (mref == null)
                                 throw new InternalError(dn + " not found");
                             requiresPublic.add(mref.descriptor());


On Tue, Nov 3, 2015 at 3:23 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 03/11/2015 02:27, Alex Buckley wrote:
>
>>
>> It's currently underspecified in Configuration::resolve as "A readability
>> graph is then constructed to take account of implicitly declared
>> dependences (requires public)."
>>
> Yes, the javadoc does indeed need more work.
>
>
>> We'll have to think about the implication of com.baz in layer1 sometimes
>> offering a 'requires public' on com.bar in layer1, and sometimes offering a
>> 'requires public' on com.bar in layer2, depending on who is reading com.baz
>> in layer1.
>>
> Yes, although for the configuration then the read edges are always to
> modules in same configuration or to modules in parent layers. So in Ali's
> example then the configuration for layer2 should have have com.foo reading
> both com.baz and com.bar in layer1. At runtime then com.foo might decide to
> also read com.bar at 2 but it's playing with fire at that point.
>
> In any case, the issue that Ali ran into turns out to be a small oversight
> in the implementation, easily fixed. There is however another case that
> will need yet more thought and that is where an indistinguishable com.bar
> is in both layers. If they are different (meaning not equal) then the
> implementation will be correct. This is somewhat of a corner case but will
> need to be handled too.
>
> -Alan.
>



-- 

Best Regards,
Ali Ebrahimi