Hello,
Thanks' for this proposal. It will be helpful for tools like NetBeans IDE.
I assume that "...it provides a mapping from a module name to a location
on the host system where the contents of the module can be found. The
representation of the module itself could be any form that could
otherwise appear in a directory on the module path, such as a modular
jar or exploded module... " means we will be able to refer to folder
with exploded module (compiled class files) in properties file e.g.
module.name=/{project_folder}/classes//./ This will speed up operations
like Run when Compile on Save is used, Run the project in general,...
for projects. Creation of jar file will not be necessary and whole
edit-compile-run/debug cycle will be faster.
This will definitely help.
Listing of directories on modulepath continues to be a main way how to
refer to modules, right?
What can be the problem is the necessity to modify the
/modulepath.properties/ file in a case module name was changed inside
module-info.java. Developer needs to remember to make changes in 2
places in such a case. And if module is delivered as 3rd party lib
(.jar) then even developer of project using such lib might not be aware
that module name has been changed and will see some javac error as the
first sign of such change.
I think that allowing modulepath to accept listing of particular modules
will be still a convenient solution for developers and should be
considered. modulepath will offer the flexibility to refer to just a few
folders treated as modules repositories. And at the same time point to
several jar files/folders (representing modules) in a case these are
placed at different folders on disk. This will allow developers to have
e.g. per project module repository with various modules main project is
using and at the same time to refer to additional library projects the
main project depends on. These will be listed on modulepath as
folder/jar per module.
Anyway this proposal is the improvement for us.
Thanks' Martin
On 8.1.2016 00:39, Jonathan Gibbons wrote:
This is a follow-up to some of the recent email discussions regarding
the use of the module path.
The "State of the Module System" [1] defines a _module path_ as follows:
A module path is a sequence of directories containing module
artifacts which are searched, in order, for the first artifact that
defines a suitable module.
However, build systems may find it inconvenient to aggregate the
necessary set of modules for an application into such a sequence of
directories. For example, see [2]. In general, it is undesirable to
have to copy jar files into directories on the module path, partly
because of the IO cost involved, and partly because of the number of
duplicated files that might ensue.
One possibility is to allow the module path to directly contain
entries specifying modules, as compared to directories containing
modules. See JDK-8144665 [3]. While feasible, that would put us back
in the world of long paths, and hence long command lines, which are
problematic on some platforms, and which have led to ad-hoc
workarounds such as the use of so-called @-files, to workaround around
any platform-specific command line limitations.
Another possibility would be to use symbolic links, so that the
directories on the module path do not directly contain the necessary
jar files but instead contain links to those jar files. But symbolic
links are not uniformly supported on all systems, which would make
such an approach somewhat problematic.
This note suggests a similar-but-different approach.
The proposal is that it should be possible to represent an entry on
the module path as a text file in Java properties file format, such
that it provides a mapping from a module name to a location on the
host system where the contents of the module can be found. The
representation of the module itself could be any form that could
otherwise appear in a directory on the module path, such as a modular
jar or exploded module. Just as a file system directory provides a
mapping from a name to the content of a module, so too could such a
properties file, which could be created at minimal cost, without
copying any files, and which would work uniformly across all
platforms. Although there need not be any inherent restrictions on
the use of such entries on the module path, in the extreme case, the
location of all the application modules for an application could be
specified in a single properties file entry on the application module
path.
While conceptually similar to the use of @-files, the use of property
files to express a large number of entries on a module path would
provide a more structured solution that would be uniformly adopted
across all tools that process module paths, including but not limited
to the Java launcher (java), linker (jlink), and compiler (javac).
-- Jon
[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
[2]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005582.html
[3] https://bugs.openjdk.java.net/browse/JDK-8144665
