Automatic module names - "requires package" proposal

[Stephen Colebourne]

On 3 February 2017 at 15:40, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> I think automatic modules are critical to migration, otherwise things move
> at the pace of the slowest project (which might be 0km/h in case of
> unmaintained projects). A lot of the discussion here has been on the naming
> but automatic modules but the other important benefit of automatic modules
> is that they support bridging to the class path.
>
> As regards the example naming clash then these two projects might already
> get complaints over their poor choice of artifacts, esp. when artifacts for
> both projects are in same directory (say where someone distributes with all
> JAR files in a `lib` directory).

We can't close our eyes to this problem. There can be naming clashes
as above, naming problems due to having to guess a project's choice of
a module name. We need to take the guesswork out, and have something
based on Java compilation elements.

As such, I'd like to propose an alternative based on packages that
could still be feasible in the time available:

1) Have two types of `requires` clause - one for modules and one for packages
2) When requiring a package, that package must be available, either on
the classpath or in a module
3) When requiring a package, the package must not be found in a module
that is explicitly referenced
4) Fully modularized applications do not have `requires package` -
this is a migration feature like `open modules`

module com.org.a {
  // dependency on a module (modular jar)
  requires module com.org.b;
  requires module com.org.c;

  // dependency on packages (modular jar or classpath)
  requires package com.org.d;
  requires package com.org.d.x;
  requires package com.org.d.y;
}

In the example above, the three explicitly specified packages must not
be found in module `com.org.b` or `com.org.c` (rule #3). They must
instead be found in a jar on the classpath (each package must be found
only in one jar), or in a future module (which could have any name,
not just `com.org.d` or `d`).

The `requires package` provides the "bridge" to the classpath and
older jars that is desired, without the mess of automatic modules.
Note that there would be no automatic modules as currently planned in
this proposal.

(FWIW, in the implementation, I'd imagine that each required package
would be created as a separate module, using the same openess/security
design as automatic modules today)

Stephen