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

[Ross Goldberg]

> 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.

Maybe a separate option could be added to recursively compile all *.java
files found under the -sourcepath / —module-source-path without explicitly
listing them in the _sourcefiles_ arguments. Thus, all options would be
consistent & backwards compatible, yet users could use a more concise
syntax that is probably applicable to the vastly overwhelming majority of
all javac invocations.

> 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?

I’m writing a plugin for Gradle to support modules, so I should support any
conceivable module directory structure, preferably without any manual
configuration or forced conventions.

I already have code that uses the g:com.github.javaparser:javaparser-core
library to parse module names from module-info.java files.

Besides the many obvious plugin development & runtime negatives, requiring
an otherwise unnecessary library subjects my plugin & its users to the
library’s bugs, and to any compatibility issues and/or update lags caused
by changes in Java or in other libraries (e.g., Java version format issues
lead to delays in adoption of recent versions of Java due to library
incompatibilities, and library module issues are still causing delays in
adoption of JPMS).

Given that the module name is functionally unnecessary in the command line,
and that it requires knowing it and correctly aligning it between command
line & module-info.java, it seems odd to require it.

I do see the potential documentation use, but I feel it should be optional
rather than required. Much of the time, the module name will be in the
directory hierarchy, so an explicit module name will even be redundant for
a documentation basis.

I can’t imagine that the code to handle any of my suggestions is difficult
or time consuming to write, maintain, document, or teach. The benefits seem
to vastly outweigh the costs.

Thanks again,

Ross

On Fri, Aug 31, 2018 at 4:43 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180901/d4751717/attachment.html>