Specifying module paths

[Martin Balin]

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