module lookup on behalf of automatic modules

[stephan-herrmann]

Debugging #2749 for #2748 I was puzzled by the following:

We have a few code locations where we differentiate if we should look for all observable modules or only for all named modules.

JLS §7 introduces automatic modules without any mention of what an auto module can read.

JEP 261 has nothing helpful in this regard.

Javadoc of ModuleFinder.of() defines how an auto module is identified, and what it exports, but no word on what it reads.

Finally the Javadoc of package java.lang.module declares:

If B is an automatic module, then A "reads" every other enumerated automatic module. (It is "as if" an automatic module has 'requires transitive' directives for every other enumerated automatic module).

In previous bugs like bug 518282 we worked from a version that said

For each enumerated module X that is automatic: X "reads" every other enumerated module

where no restriction to automatic modules was present. I have no record of what "specification" we worked from in those days. I only vividly recall that we had a tremendously hard time to gather any sufficient set of specifications.

At the same time we might want to check for similar loose ends regarding the unnamed module.

[stephan-herrmann]

I played a bit with this but am no longer sure there's much to be gained here.

First attempt: Invent a new flavor of LookupStrategy which finds packages / types only within auto modules, and use that strategy when searching on behalf of an auto module. First question: would this imply that auto modules cannot see any system modules (aside from java.base perhaps)?

At this point some module tests claimed foul indeed, but the way this surfaced was the dreaded "The type {0} cannot be resolved. It is indirectly referenced from required .class files". Simply hiding types required by binary types is never nice. In particular when the requesting binary type was compiled on the classpath, where the reference was legal! And when the classfile actually exists on the build path.

Next I tried to add a module.canAccess(type.fPackageBinding) stanza into URB.resolveType() as to convert an inaccessible BTB into a ProblemBinding(NotAccessible). Result:

// named module
package pnamed;
class Named { public String name() { return "Named"; } }

// auto module
class Auto extends Named {}

// client module
new Auto().name()

Now the message send name() would complain that this method doesn't exist in class Auto. This isn't wrong, but not the right way to communicate to users either.

Here's what javac reports in this situation:

test/Main.java:5: error: cannot access Named
                new Auto().name();
                          ^
  class file for pnamed.Named not found
1 error

Also this isn't wrong, but users will ask: why didn't you find it, it's right there!

For lack of ideas how to report this without annoying users I'll let it rest.