_module-specific form_ for --module-source-path from Bug # 8208609

[Jonathan Gibbons]

On 8/31/18 12:51 PM, Ross Goldberg wrote:
> Can someone provide some details for the _module-specific form_ 
> enhancement for --module-source-path from 8208609? 
> (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8208609)
>
> Is a _file-path_ always to a file, or could it be to a directory?

By itself, "path" is an overloaded and potentially ambiguous term: it 
can mean the path for a specific item in a file system (as may be 
represented by  java.nio.file.Path) or it can mean a search path, like a 
class path, source path or module path. So I try and qualify which 
variant I mean.
_file-path_ is used to mean a reference to a specific item in the file 
system.  In the context of the module source path, it probably will be a 
directory, in which case it should be the directory that is the root of 
the package hierarchy for some or all of the module's source code.

>
> If directories are supported, are all *.java file descendants compiled 
> with a package hierarchy rooted at the directory?
Directories, are supported; no, files in the subdirectories are not 
automatically compiled. That never was (and still is) true for 
-sourcepath, it is likewise true for the module source path.
>
> If directories aren't supported, why?  The additional error conditions 
> (e.g., 1 _file_path_ being a descendant of another) should be easy to 
> check, and allowing directories could significantly shorten command lines.
n/a. See previous answer.
>
> If a file is included in a module's path via a _file-path_, must the 
> file also be included in the standard _sourcefiles_ arguments?  If so, 
> that seems redundant…
You put directories on the module source path. You put the specific 
files to be compiled in the _sourcefiles_ argument.   While it might 
seem redundant, it is pragmatically necessary to put the directories on 
the module source path as well: this is required to help determine the 
enclosing module, by making it possible to find the corresponding 
module-info.java file.

Note that you only need use --module-source-path when compiling multiple 
modules at once. If you're just compiling one module at a time, you can 
use --source-path.

>
> Will you support {,} alternates in the _module-specific form_?  That 
> would also help shorten command lines.

There are no plans to do that at this time.

>
> Requiring that the module name be specified before the equals sign 
> makes it harder for build systems to use --module-source-path. They 
> must either:
>
> 1. parse module-info.java: performance (must parse file), 
> compatibility (might require parser updates if module-info.java spec 
> is changed)
> 2. read from directory structure based on convention: flexibility 
> (limits layouts)
> 3. read from build config file: maintenance (config module name must 
> align with module-info.java module name)

If your files follow the suggested layout, you can use the 
module-pattern form, which does not require any module name to be 
specified on the command line.  The module-specific form is for those 
cases where the file layout does not follow the standard form, in which 
case it is not unreasonable to specify the name of the module whose 
source path is being specified.

>
> Could you provide another option, possibly named --module-source, that 
> doesn't require the module name?

Unlikely.   It is not clear that there is a problem here that needs to 
be solved.
>
> There should obviously always be one and only one module-info.java in 
> each module's path, so javac should be able to get the module name 
> from that file instead of from the command line.
The current syntax matches that used for the --patch-module option. 
There is benefit in consistency.
There is also benefit in having the user (or build system) explicitly 
provide the module name, both for documentation and for consistency 
checking.
>
> Thanks for any info,

Are your concerns related to any specific build system, or to direct use 
of the javac command in a Makefile or script, or just abstract academic 
concerns?
>
> Ross

-- Jon