According to the JDK ticket, Alan says: "anything that implements "module path" would need to support this." I assumed this also means java.exe. The ticket also states they want to get away from "long command lines". Based on these remarks, it should be affecting forking too. On Jan 9, 2016 10:57 AM, "Tibor Digana" <[email protected]> wrote:
> a. > Regarding execution of forked JVM in Surefire it has nothing to do with > javac, nothing but java. > Regarding building forked jar, then yes this may have an impact because we > create jar file which contains manifetst having Class-Path. > > b. > Is the classpath in manifest going to be deprecated or removed? > > c. > Is the javac switch "-cp" going to be deprecated or removed in future? > > d. > Maybe a solution from me. > Imaging this command: > > javac -modulepath dir1:dir2:dir3 -modulepathfactory ./mfactory.jar > > If -modulepathfactory is unspecified then Oracle's default is applied. > Compiler API can be extended with new SPI interface (spi=global in VM :( ) > or whatever other interface. > > It would be nice and modern style to have javac which understands a > scripting language along with jar file in -modulepathfactory. > In such case: > javac -modulepath ... -modulepathfactory mf.groovy > > Cheers > Tibor > > > > On Sat, Jan 9, 2016 at 4:41 PM, Robert Scholte <[email protected]> > wrote: > > > Hi Paul, > > > > thanks for your response. > > > > I'm not sure if I follow you with the forking problem. I guess you're > > talking about the fork option of surefire. > > Maybe one of the active surefire committers can explain how classpaths > are > > handled right now and if this has a conflict with this proposal. > > Based on what I read the name of the properties file doesn't matter. > > > > 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. > >>> > >> AFAIK buildtools use the compiler-api, where the limitation is the max > > array size. I wonder if the commandline should still be used as first > > reference. IMHO if commandlines become that long you should switch to a > > buildtool. > > > > There are 2 things important to me: > > - reference must result in a single file > > - predictable order > > > > For those who aren't aware of it: java.io.File.list() returns an array of > > strings naming the files and directories in the directory denoted by this > > abstract pathname. > > But the javadoc also says: There is no guarantee that the name strings in > > the resulting array will appear in any specific order; they are not, in > > particular, guaranteed to appear in alphabetical order. > > I can confirm this, I've seen different orders for different OS's. > > > > To be honest, I don't know if the order of "requires" in the module-info > > has effect on the "classpath", nor how transitive modules behave. So if > the > > predictable order is controlled by the module-info, then it is not a > Maven > > problem anymore. > > > > thanks, > > Robert > > > > Op Fri, 08 Jan 2016 20:14:33 +0100 schreef Paul Benedict < > > [email protected]>: > > > > > > It sounds like Maven will have to generate many .properties file in a > >> build. > >> 1) Modules to compile main source > >> 2) Modules to compile test source > >> 3) Modules to execute tests > >> 4) And what about forking? > >> > >> I am concerned #4 is going to create issues unless the .properties file > >> name is unique enough. Perhaps it can be based on process id. > >> > >> > >> Cheers, > >> Paul > >> > >> On Fri, Jan 8, 2016 at 11:42 AM, Robert Scholte <[email protected]> > >> wrote: > >> > >> FYI, a new idea to solve our modulepath issue. > >>> Any feedback is appreciated. > >>> > >>> thanks, > >>> Robert > >>> > >>> -------- Forwarded Message -------- Subject: Specifying module paths > >>> Date: > >>> Thu, 07 Jan 2016 15:39:43 -0800 From: Jonathan Gibbons > >>> <[email protected]> <[email protected]> To: > >>> jigsaw-dev > >>> <[email protected]> <[email protected]> > >>> > >>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Cheers > Tibor >
