Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[Stephen Colebourne]

On 26 April 2017 at 19:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 26/04/2017 18:35, Stephen Colebourne wrote:
>
>> :
>> - an incomplete module defines as many dependencies as it can
>> - an incomplete module also depends on the classpath
>> - the current automatic module concept ceases to exist
>> (an incomplete module is not an automatic module, as it doesn't get to
>> read all other modules. It only gets to read the classpath)
>>
> This is along the lines of what we've previously tossed around as `requires
> $CLASSPATH`. The JAR files on your class path may expose type in other
> libraries that get migrated to modules. In the extreme then all the
> dependences are migrated so that the class path is empty. So more
> readability is needed to avoid lock step migration (it's the same
> readability that automatic modules get today).

I'm working on the principle that the classpath sees all modules anyway.

FWIW, I'll go on record and say that I think the bifurcation between
the classpath and modulepath is a mistake that will be damaging long
term. I would prefer to see all jar files continue to sit on the
classpath, just that some also have additional metadata controlling
their exports and dependencies. The complete/incomplete module
declarations described above, would essentially allow this AFAICT.

Mark R wrote:
> This approach would, moreover, still require existing projects
> to do new releases, which as you indicate above can be very costly and
> in many cases unlikely to happen.

True, but the module metadata would always be correct no matter how
many releases are needed (much easier for Maven Central to validate
this too). Any project that adds an incomplete module declaration is
obviously still alive, so much more likely than average to finish the
process and become a complete module.

Stephen