_module-specific form_ for --module-source-path from Bug # 8208609
Jonathan Gibbons
jonathan.gibbons at oracle.com
Sat Sep 1 16:17:15 UTC 2018
On 9/1/18 7:17 AM, Ross Goldberg wrote:
> > 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.
Look at --module <module>[,<module.}* which is effectively equivalent to
compiling all the source files for the named modules where the source
file is newer than the corresponding class file. If you want to find and
compile all files in those directories, it is easy enough to use the NIO
file API to iterate such files.
>
> > 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.
OK, thanks for the context info.
>
> 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.
It is already the case that there is a precedent for the
"<module-name>=..." convention for module-specific command-line args in
various JDK tools, including, but not limited to the --patch-module option.
There are other considerations too ... if javac were to support these
"anonymous" module source paths, and an error appears in it, how should
we identify the path in error messages? The module name is useful in
that context as well.
Finally, this change is a relatively small one, simply exposing
functionality provided in the JavaFileManager API, thereby aligning
functionality provided on the javac command line with that already
available to clients of the Java Compiler API.
-- Jon
>
> Thanks again,
>
> Ross
>
> On Fri, Aug 31, 2018 at 4:43 PM Jonathan Gibbons
> <jonathan.gibbons at oracle.com <mailto: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/b6a067c9/attachment-0001.html>
More information about the compiler-dev
mailing list