Discussion:
modulepath and classpath mixture
(too old to reply)
Robert Scholte
2016-02-22 20:44:05 UTC
Permalink
Hi,

first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to work
with jars and class-folders.

Here's my use case: I noticed that if I add a module-info to src/main/java
and put all compile-scoped dependencies to the module path, all compiles
fines.
I assume that developers are less interested in adding a module-info.java
file to src/test/java, so that's what I'm doing right now too.
Now it seems that I *must* add compile + test scoped to the *classpath* to
be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.

I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.

thanks,
Robert
Alex Buckley
2016-02-23 00:30:16 UTC
Permalink
Hi Robert,
Post by Robert Scholte
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
Sounds good.
Post by Robert Scholte
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
To clarify: you are NOT putting module-info.java in src/test/java.
Post by Robert Scholte
Now it seems that I *must* add compile + test scoped to the *classpath*
to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
Your first approach sounds preferable. Can you copy-paste a minimized
invocation of javac that works, and that doesn't work?

Alex
Robert Scholte
2016-02-23 21:12:27 UTC
Permalink
Post by Alex Buckley
Hi Robert,
Post by Robert Scholte
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
Sounds good.
Post by Robert Scholte
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
To clarify: you are NOT putting module-info.java in src/test/java.
Post by Robert Scholte
Now it seems that I *must* add compile + test scoped to the *classpath*
to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
Your first approach sounds preferable. Can you copy-paste a minimized
invocation of javac that works, and that doesn't work?
Alex
Here's the debug output when calling 'mvn test'.
This doesn't work:

[DEBUG] Classpath:
[DEBUG]
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\test-classes
[DEBUG] C:\Users\Robert
Scholte\.m2\repository\junit\junit\4.12\junit-4.12.jar
[DEBUG] C:\Users\Robert
Scholte\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
[DEBUG] Modulepath:
[DEBUG]
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\classes
[DEBUG] C:\Users\Robert
Scholte\.m2\repository\org\codehaus\plexus\plexus-utils\3.0.22\plexus-utils-3.0.22.jar
[DEBUG] C:\Users\Robert
Scholte\.m2\repository\org\apache\commons\commons-lang3\3.4\commons-lang3-3.4.jar
[DEBUG] Source roots:
[DEBUG]
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\src\test\java
[DEBUG]
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\generated-test-sources\test-annotations
[DEBUG] Command line options:
[DEBUG] -d
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\test-classes
-classpath
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\test-classes;C:\Users\Robert
Scholte\.m2\repository\junit\junit\4.12\junit-4.12.jar;C:\Users\Robert
Scholte\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar;
-modulepath
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\classes;C:\Users\Robert
Scholte\.m2\repository\org\codehaus\plexus\plexus-utils\3.0.22\plexus-utils-3.0.22.jar;C:\Users\Robert
Scholte\.m2\repository\org\apache\commons\commons-lang3\3.4\commons-lang3-3.4.jar;
-sourcepath
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\src\test\java;E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\generated-test-sources\test-annotations;
-s
E:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\generated-test-sources\test-annotations
-g -nowarn -target 1.9 -source 1.9 -encoding UTF-8

Result:
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/E:/java-workspace/apache-maven-maven/maven/maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[25,41]
package org.apache.maven.building.Problem does not exist
[ERROR]
/E:/java-workspace/apache-maven-maven/maven/maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemCollectorTest.java:[24,41]
package org.apache.maven.building.Problem does not exist

followed by a lot of 'cannot find symbol'.

If all modulepath entries were added to the classpath instead, then it
compiles fine.

thanks,
Robert
Jonathan Gibbons
2016-02-23 00:52:50 UTC
Permalink
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
thanks,
Robert
Robert,

We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by default,
the unnamed module (i.e. code on the classpath) only has observability
of the modules in the system image. To make modules on the module path
observable, you need to use the -addmods option.

-- Jon
Robert Scholte
2016-02-23 20:48:50 UTC
Permalink
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
Now it seems that I *must* add compile + test scoped to the *classpath*
to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by default,
the unnamed module (i.e. code on the classpath) only has observability
of the modules in the system image. To make modules on the module path
observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,

this would indeed explain what I'm facing right now. However, adding
-addmods gives me the following exception:
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
com.sun.tools.javac.main.Arguments.error(***@9-ea/Arguments.java:708)

Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would mean
that I first need to discover and read all module-info files.

thanks,
Robert
Jonathan Gibbons
2016-02-23 21:06:28 UTC
Permalink
Post by Robert Scholte
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like
to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath, so
the modules keeps their inner related structure, but it seems that
the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules on
the module path observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,
this would indeed explain what I'm facing right now. However, adding
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would
mean that I first need to discover and read all module-info files.
thanks,
Robert
Sorry, I should have been more explicit.

Both javac and java (the launcher) accept an option "-addmods
<module-name>,..." which can be used to name modules to be included in
the module graph. Confusingly, for javac, the option is listed under
javac -X (that's a bug we will fix), but setting that aside, here's what
the command line help says:

-addmods <modulename>[,<modulename>...] Root modules to resolve in
addition to the initial modules

"java -help" says effectively the same.


So yes, the option takes a list of module names, not module paths.

-- Jon
Jonathan Gibbons
2016-02-23 21:14:32 UTC
Permalink
Post by Jonathan Gibbons
Post by Robert Scholte
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like
to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath,
so the modules keeps their inner related structure, but it seems
that the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules on
the module path observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,
this would indeed explain what I'm facing right now. However, adding
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would
mean that I first need to discover and read all module-info files.
thanks,
Robert
Sorry, I should have been more explicit.
Both javac and java (the launcher) accept an option "-addmods
<module-name>,..." which can be used to name modules to be included in
the module graph. Confusingly, for javac, the option is listed under
javac -X (that's a bug we will fix), but setting that aside, here's
-addmods <modulename>[,<modulename>...] Root modules to resolve in
addition to the initial modules
"java -help" says effectively the same.
So yes, the option takes a list of module names, not module paths.
-- Jon
... but that being said, note that you don't have to list all the
modules on the module path. You only need to list root modules, and
javac will determine the transitive closure of all the necessary modules.

So, if you're writing tests in the unnamed module, to test a module M,
the chances are that you only need "-addmods M".


Alan wrote a separate email about different compilation scenarios. Note
that in many/most of those cases, no -addmods was necessary.


-- Jon
Robert Scholte
2016-02-23 21:22:01 UTC
Permalink
On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons
Post by Jonathan Gibbons
Post by Jonathan Gibbons
Post by Robert Scholte
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like
to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath, so
the modules keeps their inner related structure, but it seems that
the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules on
the module path observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,
this would indeed explain what I'm facing right now. However, adding
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would
mean that I first need to discover and read all module-info files.
thanks,
Robert
Sorry, I should have been more explicit.
Both javac and java (the launcher) accept an option "-addmods
<module-name>,..." which can be used to name modules to be included in
the module graph. Confusingly, for javac, the option is listed under
javac -X (that's a bug we will fix), but setting that aside, here's
-addmods <modulename>[,<modulename>...] Root modules to resolve in
addition to the initial modules
"java -help" says effectively the same.
So yes, the option takes a list of module names, not module paths.
-- Jon
... but that being said, note that you don't have to list all the
modules on the module path. You only need to list root modules, and
javac will determine the transitive closure of all the necessary modules.
So, if you're writing tests in the unnamed module, to test a module M,
the chances are that you only need "-addmods M".
This makes sense. And although I still don't like the fact that this
requires me to read the module-info, this should be possible for the
target/mods/m (since it is already compiled).
So my response to Alan was probably a bit too fast.
This requires some tricks on our side to stay compatible with lower Java
versions while adding some code to read the module-info.

thanks,
Robert
Post by Jonathan Gibbons
Alan wrote a separate email about different compilation scenarios. Note
that in many/most of those cases, no -addmods was necessary.
-- Jon
--
Using Opera's mail client: http://www.opera.com/mail/
Jonathan Gibbons
2016-02-23 23:15:26 UTC
Permalink
Post by Robert Scholte
On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons
Post by Jonathan Gibbons
Post by Jonathan Gibbons
Post by Robert Scholte
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new
-mp options, these matches better with the way Apache Maven would
like to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the
module path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath,
so the modules keeps their inner related structure, but it seems
that the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules
on the module path observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,
this would indeed explain what I'm facing right now. However,
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would
mean that I first need to discover and read all module-info files.
thanks,
Robert
Sorry, I should have been more explicit.
Both javac and java (the launcher) accept an option "-addmods
<module-name>,..." which can be used to name modules to be included
in the module graph. Confusingly, for javac, the option is listed
under javac -X (that's a bug we will fix), but setting that aside,
-addmods <modulename>[,<modulename>...] Root modules to resolve in
addition to the initial modules
"java -help" says effectively the same.
So yes, the option takes a list of module names, not module paths.
-- Jon
... but that being said, note that you don't have to list all the
modules on the module path. You only need to list root modules,
and javac will determine the transitive closure of all the necessary
modules.
So, if you're writing tests in the unnamed module, to test a module
M, the chances are that you only need "-addmods M".
This makes sense. And although I still don't like the fact that this
requires me to read the module-info, this should be possible for the
target/mods/m (since it is already compiled).
So my response to Alan was probably a bit too fast.
This requires some tricks on our side to stay compatible with lower
Java versions while adding some code to read the module-info.
thanks,
Robert
When we've had discussions about how these options might work, we've
generally assumed you might have some a priori knowledge of the module
name from some other context, rather than having to rely on reading
module info.

-- Jon
Post by Robert Scholte
Post by Jonathan Gibbons
Alan wrote a separate email about different compilation scenarios.
Note that in many/most of those cases, no -addmods was necessary.
-- Jon
Robert Scholte
2016-02-24 19:12:31 UTC
Permalink
On Wed, 24 Feb 2016 00:15:26 +0100, Jonathan Gibbons
Post by Jonathan Gibbons
Post by Robert Scholte
On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons
Post by Jonathan Gibbons
Post by Jonathan Gibbons
Post by Robert Scholte
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new
-mp options, these matches better with the way Apache Maven would
like to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the
module path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath,
so the modules keeps their inner related structure, but it seems
that the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules
on the module path observable, you need to use the -addmods option.
-- Jon
Hi Jonathan,
this would indeed explain what I'm facing right now. However, adding
Caused by: java.lang.IllegalArgumentException: -addmods requires an
argument
at
Is -addmods followed by the same entries as -modulepath or by the
modulenames. I really hope it is not the latter, because that would
mean that I first need to discover and read all module-info files.
thanks,
Robert
Sorry, I should have been more explicit.
Both javac and java (the launcher) accept an option "-addmods
<module-name>,..." which can be used to name modules to be included
in the module graph. Confusingly, for javac, the option is listed
under javac -X (that's a bug we will fix), but setting that aside,
-addmods <modulename>[,<modulename>...] Root modules to resolve in
addition to the initial modules
"java -help" says effectively the same.
So yes, the option takes a list of module names, not module paths.
-- Jon
... but that being said, note that you don't have to list all the
modules on the module path. You only need to list root modules, and
javac will determine the transitive closure of all the necessary modules.
So, if you're writing tests in the unnamed module, to test a module M,
the chances are that you only need "-addmods M".
This makes sense. And although I still don't like the fact that this
requires me to read the module-info, this should be possible for the
target/mods/m (since it is already compiled).
So my response to Alan was probably a bit too fast.
This requires some tricks on our side to stay compatible with lower
Java versions while adding some code to read the module-info.
thanks,
Robert
When we've had discussions about how these options might work, we've
generally assumed you might have some a priori knowledge of the module
name from some other context, rather than having to rely on reading
module info.
-- Jon
Hmm, would have been nice if I had known about these discussions, because
I don't think that this is a valid assumption from a Maven perspective.
Ideally developers simply add module-info.java files to the source-roots
of their choice and Maven should be able to construct the correct set of
javac arguments.
I don't expect developers to open a jar to see if there's a module-info
available. Actually, how can he figure out the module name, since the
module-info is a compiled file?
Anyhow, Maven is capable to discover the module name when required, but it
is not that efficient. Maybe it is time to work on some feedback to
describe the issues I'm facing regarding some of the javac options.

thanks,
Robert
Post by Jonathan Gibbons
Post by Robert Scholte
Post by Jonathan Gibbons
Alan wrote a separate email about different compilation scenarios.
Note that in many/most of those cases, no -addmods was necessary.
-- Jon
--
Using Opera's mail client: http://www.opera.com/mail/
Alan Bateman
2016-02-24 20:46:43 UTC
Permalink
Post by Robert Scholte
Hmm, would have been nice if I had known about these discussions,
because I don't think that this is a valid assumption from a Maven
perspective. Ideally developers simply add module-info.java files to
the source-roots of their choice and Maven should be able to construct
the correct set of javac arguments.
I don't expect developers to open a jar to see if there's a
module-info available. Actually, how can he figure out the module
name, since the module-info is a compiled file?
One way is `jar --file foo.jar -p`. That will print the module
descriptor when the JAR file is a modular JAR. There is API support for
reading the binary form of the module declaration too.

-Alan
Robert Scholte
2016-02-27 11:25:32 UTC
Permalink
Hi,

I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.

thanks,
Robert

[1] http://openjdk.java.net/jeps/261


On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
Now it seems that I *must* add compile + test scoped to the *classpath*
to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by default,
the unnamed module (i.e. code on the classpath) only has observability
of the modules in the system image. To make modules on the module path
observable, you need to use the -addmods option.
-- Jon
--
Using Opera's mail client: http://www.opera.com/mail/
Jonathan Gibbons
2016-02-27 15:56:22 UTC
Permalink
At the risk of opening bikesheds, if we go that way, I would suggest
just -ALL- or just a new option -addallmods.

-- Jon
Post by Robert Scholte
Hi,
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set
of moduleEntries on the modulePath are already chosen with care and
are in the end all required to be able to compile the test-classes
without the need of knowing the name of the module being used to
compile with.
thanks,
Robert
[1] http://openjdk.java.net/jeps/261
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like
to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on
the modulepath and all test-scoped dependencies on the classpath, so
the modules keeps their inner related structure, but it seems that
the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on
the classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by
default, the unnamed module (i.e. code on the classpath) only has
observability of the modules in the system image. To make modules on
the module path observable, you need to use the -addmods option.
-- Jon
Robert Scholte
2016-03-06 14:01:35 UTC
Permalink
Hi,

I've asked for some feedback and there seems to be concerns with split
packages when there are two or more modules on the module path that export
the same package.
Unless I misunderstand the issue, I'd say you have the same problem with
-addmods. If you add mod1 and mod2, which both export the same package,
you have exactly the same issue, right?

When talking about exports it made me realize there's probably another
issue: only the exported packages of the "main"-module are accessible,
right? Since src/test/java has no module-info, the -Xpatch is useless.
An idea that comes to my mind is something like -mainModule <arg>, where
are either a jar or directory containing module-info. All its classes can
be accessed by the classes on the classpath, all other modules keep their
package access restrictions.

thanks,
Robert

On Sat, 27 Feb 2016 16:56:22 +0100, Jonathan Gibbons
Post by Jonathan Gibbons
At the risk of opening bikesheds, if we go that way, I would suggest
just -ALL- or just a new option -addallmods.
-- Jon
Post by Robert Scholte
Hi,
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set
of moduleEntries on the modulePath are already chosen with care and are
in the end all required to be able to compile the test-classes without
the need of knowing the name of the module being used to compile with.
thanks,
Robert
[1] http://openjdk.java.net/jeps/261
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
Post by Alex Buckley
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing
right now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
thanks,
Robert
Robert,
We definitely need some more detailed notes on setting up javac
compilations (note to self!) but one thing to note is that by default,
the unnamed module (i.e. code on the classpath) only has observability
of the modules in the system image. To make modules on the module path
observable, you need to use the -addmods option.
-- Jon
--
Using Opera's mail client: http://www.opera.com/mail/
Alan Bateman
2016-03-07 12:13:38 UTC
Permalink
Post by Robert Scholte
Hi,
I've asked for some feedback and there seems to be concerns with split
packages when there are two or more modules on the module path that
export the same package.
Unless I misunderstand the issue, I'd say you have the same problem
with -addmods. If you add mod1 and mod2, which both export the same
package, you have exactly the same issue, right?
Yes, although at least if you specify the module names to -addmods then
you are being explicit as to the additional modules to resolve. The
issue with -addmods ALL-NAMED (or what the token is) is that it will
resolve all modules that can be found via the application module path
and so would need to be used with great care.
Post by Robert Scholte
When talking about exports it made me realize there's probably another
issue: only the exported packages of the "main"-module are accessible,
right? Since src/test/java has no module-info, the -Xpatch is useless.
An idea that comes to my mind is something like -mainModule <arg>,
where are either a jar or directory containing module-info. All its
classes can be accessed by the classes on the classpath, all other
modules keep their package access restrictions.
I don't think I understand the issue here. Using -Xpatch doesn't change
the module declaration or export. It can be used to override or augment
the module content, it just can't override the module declaration. It
can be used in conjunction with -XaddReads and -XaddExports to read
additional modules or export additional packages. For example, if a
patch adds types to a new package then you could export that package
with -XaddExports. If the patch injects tests into an existing package
then those tests might have new dependences and requires compiling or
running with -XaddReads:$MODULE=junit for example.

-Alan
Sander Mak
2016-03-07 13:53:28 UTC
Permalink
I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration. It can be used in conjunction with -XaddReads and -XaddExports to read additional modules or export additional packages. For example, if a patch adds types to a new package then you could export that package with -XaddExports. If the patch injects tests into an existing package then those tests might have new dependences and requires compiling or running with -XaddReads:$MODULE=junit for example.
I was playing around with exactly this yesterday, and this is what I ended up with:

javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find src-test -name '*.java')

java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-addmods javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest

Which patches my application module to contain a unit test, and then exposes my application module to junit at runtime (which is used as automatic module here). This works as expected.


-- Sander
Alan Bateman
2016-03-07 14:20:46 UTC
Permalink
Post by Sander Mak
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find src-test -name '*.java')
java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-addmods javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
Which patches my application module to contain a unit test, and then exposes my application module to junit at runtime (which is used as automatic module here). This works as expected.
Good to see you got this working. Injecting tests into existing modules
and augmenting the module declaration so that the module reads the test
framework will be a bit advanced for many developers. I hope in time
that the IDEs and other tools will make this easy.

-Alan
Stephen Felts
2016-03-07 16:41:18 UTC
Permalink
I'm seeing a problem using ant that I suspect is related to the classloading. I think it came in build 107 or 108.

The following

<path id="modules.antcontrib.classpath">
<pathelement location="${build.install}/ant-contrib-1.0b3.jar" />
</path>
<taskdef resource="net/sf/antcontrib/antlib.xml" classpathref="modules.antcontrib.classpath" />

Is failing with

/mydir/build.xml:27: taskdef class "ignore"/> cannot be found
using the classloader AntClassLoader[/mydir_build/ant-contrib-1.0b3.jar]


This would seem like a pretty common use case.

If I comment that out, then I get the following. The named class is in the specified jar file.


/mydir/build.xml:578: typedef class name="p4versionstring" classname="weblogic.ant.taskdefs.perforce.P4VersionString"/> cannot be found
using the classloader AntClassLoader[/mydir2/weblogic.ant.taskdefs.perforce_1.1.0.0.jar]
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:607)
at org.apache.tools.ant.taskdefs.Definer.loadProperties(Definer.java:408)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:264)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(***@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(***@9-ea/Method.java:531)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.Main.runBuild(Main.java:851)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.ClassNotFoundException: name="p4versionstring" classname="weblogic.ant.taskdefs.perforce.P4VersionString"/>
at java.lang.Class.forName0(***@9-ea/Native Method)
at java.lang.Class.forName(***@9-ea/Class.java:378)
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:579)
... 18 more
Alan Bateman
2016-03-07 16:59:58 UTC
Permalink
Post by Stephen Felts
I'm seeing a problem using ant that I suspect is related to the classloading. I think it came in build 107 or 108.
This may be issue caused by the Multi-Release JAR file support that went
into jdk-9+108. Uwe Schindler brought this up on core-libs-dev over the
week and is currently tracked as JDK-8151339 [1]. Assuming you are
seeing the same issue then the proposal is to disable or revert the
change MR JAR support until the issues with URLs can be resolved. This
may happen today in order to make it into jdk-9+109.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8151339
Robert Scholte
2016-03-08 19:36:04 UTC
Permalink
Post by Sander Mak
Post by Alan Bateman
I don't think I understand the issue here. Using -Xpatch doesn't change
the module declaration or export. It can be used to override or augment
the module content, it just can't override the module declaration. It
can be used in conjunction with -XaddReads and -XaddExports to read
additional modules or export additional packages. For example, if a
patch adds types to a new package then you could export that package
with -XaddExports. If the patch injects tests into an existing package
then those tests might have new dependences and requires compiling or
running with -XaddReads:$MODULE=junit for example.
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d
mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find
src-test -name '*.java')
java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
\
-mp mods:lib-test \
-addmods
javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore
javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
Which patches my application module to contain a unit test, and then
exposes my application module to junit at runtime (which is used as
automatic module here). This works as expected.
-- Sander
When translating this to Maven it assumes that Maven is aware of the
module name of the project is it building.
Up until now that's not true. Developers specify the moduleName in the
module-info.java and it doesn't make sense to ask them to add the same
modulename to the pom (it that was possible) or the maven-compiler-plugin
configuration. Instead Maven could use some new java9 APIs to discover the
moduleName, but that would imply that from now on maven-compiler-plugin
requires Java9 runtime. I don't think that's the way we want to go right
now. Several Maven plugins have their own kind of multi-release pattern
where some codeblocks depend on a specific Maven version, but we really
want to avoid this.
I hope we can find a way where Maven can simply refer to the
classes-directory or the jar for some java/javac arguments where one would
now need to be aware of its module name.
From Mavens point of view the output directories are facts, dependencies
from the pom.xml too, as is the packaged artifact name & location, the
content of java files are a mystery and not of any interest (at least in a
classpath world ;) ).

thanks,
Robert
Paul Benedict
2016-03-08 20:06:41 UTC
Permalink
Robert, it's sounds like a chicken-and-egg problem. You need the module
name to compile but don't know it until you have compiled.

Too bad this file isn't XML so that any tool could read the module
information outside of compiling. That's what I advocated for a long time
but that battle has been lost.



Cheers,
Paul
Post by Robert Scholte
Post by Alan Bateman
I don't think I understand the issue here. Using -Xpatch doesn't change
the module declaration or export. It can be used to override or augment the
module content, it just can't override the module declaration. It can be
used in conjunction with -XaddReads and -XaddExports to read additional
modules or export additional packages. For example, if a patch adds types
to a new package then you could export that package with -XaddExports. If
the patch injects tests into an existing package then those tests might
have new dependences and requires compiling or running with
-XaddReads:$MODULE=junit for example.
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter
$(find src-test -name '*.java')
java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
\
-mp mods:lib-test \
-addmods
javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore
javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
Which patches my application module to contain a unit test, and then
exposes my application module to junit at runtime (which is used as
automatic module here). This works as expected.
-- Sander
When translating this to Maven it assumes that Maven is aware of the
module name of the project is it building.
Up until now that's not true. Developers specify the moduleName in the
module-info.java and it doesn't make sense to ask them to add the same
modulename to the pom (it that was possible) or the maven-compiler-plugin
configuration. Instead Maven could use some new java9 APIs to discover the
moduleName, but that would imply that from now on maven-compiler-plugin
requires Java9 runtime. I don't think that's the way we want to go right
now. Several Maven plugins have their own kind of multi-release pattern
where some codeblocks depend on a specific Maven version, but we really
want to avoid this.
I hope we can find a way where Maven can simply refer to the
classes-directory or the jar for some java/javac arguments where one would
now need to be aware of its module name.
From Mavens point of view the output directories are facts, dependencies
from the pom.xml too, as is the packaged artifact name & location, the
content of java files are a mystery and not of any interest (at least in a
classpath world ;) ).
thanks,
Robert
David M. Lloyd
2016-03-08 22:08:36 UTC
Permalink
The only rational solution to this problem is to completely forego the
JDK's capabilities and generate the file exclusively from the build
tooling. I expect that at some point we'll end up with a series of
tools which construct the exports list from annotated package-infos, the
requires list from a mapping or static list in the build, and a bunch of
build- and application-system specific miscellany besides. I don't
believe that any nontrivial program is likely to bundle a
module-info.java source file all, which makes me wonder if there's
actually a point to having support for it at all. Why write it when you
can generate it, and at the same time, keep all your build-related
information in one spot?
Post by Paul Benedict
Robert, it's sounds like a chicken-and-egg problem. You need the module
name to compile but don't know it until you have compiled.
Too bad this file isn't XML so that any tool could read the module
information outside of compiling. That's what I advocated for a long time
but that battle has been lost.
Cheers,
Paul
Post by Robert Scholte
Post by Alan Bateman
I don't think I understand the issue here. Using -Xpatch doesn't change
the module declaration or export. It can be used to override or augment the
module content, it just can't override the module declaration. It can be
used in conjunction with -XaddReads and -XaddExports to read additional
modules or export additional packages. For example, if a patch adds types
to a new package then you could export that package with -XaddExports. If
the patch injects tests into an existing package then those tests might
have new dependences and requires compiling or running with
-XaddReads:$MODULE=junit for example.
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter
$(find src-test -name '*.java')
java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
\
-mp mods:lib-test \
-addmods
javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore
javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
Which patches my application module to contain a unit test, and then
exposes my application module to junit at runtime (which is used as
automatic module here). This works as expected.
-- Sander
When translating this to Maven it assumes that Maven is aware of the
module name of the project is it building.
Up until now that's not true. Developers specify the moduleName in the
module-info.java and it doesn't make sense to ask them to add the same
modulename to the pom (it that was possible) or the maven-compiler-plugin
configuration. Instead Maven could use some new java9 APIs to discover the
moduleName, but that would imply that from now on maven-compiler-plugin
requires Java9 runtime. I don't think that's the way we want to go right
now. Several Maven plugins have their own kind of multi-release pattern
where some codeblocks depend on a specific Maven version, but we really
want to avoid this.
I hope we can find a way where Maven can simply refer to the
classes-directory or the jar for some java/javac arguments where one would
now need to be aware of its module name.
From Mavens point of view the output directories are facts, dependencies
from the pom.xml too, as is the packaged artifact name & location, the
content of java files are a mystery and not of any interest (at least in a
classpath world ;) ).
thanks,
Robert
--
- DML
Paul Benedict
2016-03-08 22:26:14 UTC
Permalink
Bikeshed: JDK 9 is supposed to be feature complete 5/26/16 and be RC by
next January. Is this really enough time for EE Application Server projects
and other tools like Maven to vet the capabilities?

Cheers,
Paul
Post by David M. Lloyd
The only rational solution to this problem is to completely forego the
JDK's capabilities and generate the file exclusively from the build
tooling. I expect that at some point we'll end up with a series of tools
which construct the exports list from annotated package-infos, the requires
list from a mapping or static list in the build, and a bunch of build- and
application-system specific miscellany besides. I don't believe that any
nontrivial program is likely to bundle a module-info.java source file all,
which makes me wonder if there's actually a point to having support for it
at all. Why write it when you can generate it, and at the same time, keep
all your build-related information in one spot?
Post by Paul Benedict
Robert, it's sounds like a chicken-and-egg problem. You need the module
name to compile but don't know it until you have compiled.
Too bad this file isn't XML so that any tool could read the module
information outside of compiling. That's what I advocated for a long time
but that battle has been lost.
Cheers,
Paul
Post by Alan Bateman
I don't think I understand the issue here. Using -Xpatch doesn't change
Post by Sander Mak
the module declaration or export. It can be used to override or augment the
module content, it just can't override the module declaration. It can be
used in conjunction with -XaddReads and -XaddExports to read additional
modules or export additional packages. For example, if a patch adds types
to a new package then you could export that package with -XaddExports. If
the patch injects tests into an existing package then those tests might
have new dependences and requires compiling or running with
-XaddReads:$MODULE=junit for example.
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp mods:lib-test \
-d
mods-test/javamodularity.easytext.algorithm.naivesyllablecounter
$(find src-test -name '*.java')
java -Xpatch:mods-test \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
\
-mp mods:lib-test \
-addmods
javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
-m org.junit/org.junit.runner.JUnitCore
javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
Which patches my application module to contain a unit test, and then
exposes my application module to junit at runtime (which is used as
automatic module here). This works as expected.
-- Sander
When translating this to Maven it assumes that Maven is aware of the
module name of the project is it building.
Up until now that's not true. Developers specify the moduleName in the
module-info.java and it doesn't make sense to ask them to add the same
modulename to the pom (it that was possible) or the maven-compiler-plugin
configuration. Instead Maven could use some new java9 APIs to discover the
moduleName, but that would imply that from now on maven-compiler-plugin
requires Java9 runtime. I don't think that's the way we want to go right
now. Several Maven plugins have their own kind of multi-release pattern
where some codeblocks depend on a specific Maven version, but we really
want to avoid this.
I hope we can find a way where Maven can simply refer to the
classes-directory or the jar for some java/javac arguments where one would
now need to be aware of its module name.
From Mavens point of view the output directories are facts, dependencies
from the pom.xml too, as is the packaged artifact name & location, the
content of java files are a mystery and not of any interest (at least in a
classpath world ;) ).
thanks,
Robert
--
- DML
Alan Bateman
2016-03-09 11:12:27 UTC
Permalink
Post by Paul Benedict
Robert, it's sounds like a chicken-and-egg problem. You need the module
name to compile but don't know it until you have compiled.
I think the scenario is where the module has been compiled and the issue
is the separate compilation of the tests "as if" they are in the module.

-Alan
Robert Scholte
2016-03-08 19:13:05 UTC
Permalink
Post by Alan Bateman
Post by Robert Scholte
Hi,
I've asked for some feedback and there seems to be concerns with split
packages when there are two or more modules on the module path that
export the same package.
Unless I misunderstand the issue, I'd say you have the same problem
with -addmods. If you add mod1 and mod2, which both export the same
package, you have exactly the same issue, right?
Yes, although at least if you specify the module names to -addmods then
you are being explicit as to the additional modules to resolve. The
issue with -addmods ALL-NAMED (or what the token is) is that it will
resolve all modules that can be found via the application module path
and so would need to be used with great care.
I can only speak for Maven how it wants to use it. Only the modules used
to compile the src/main/java sources will end up on the modulePath in this
case. So the set of modules has already been validated, kind of.
Post by Alan Bateman
Post by Robert Scholte
When talking about exports it made me realize there's probably another
issue: only the exported packages of the "main"-module are accessible,
right? Since src/test/java has no module-info, the -Xpatch is useless.
An idea that comes to my mind is something like -mainModule <arg>,
where are either a jar or directory containing module-info. All its
classes can be accessed by the classes on the classpath, all other
modules keep their package access restrictions.
I don't think I understand the issue here. Using -Xpatch doesn't change
the module declaration or export. It can be used to override or augment
the module content, it just can't override the module declaration. It
can be used in conjunction with -XaddReads and -XaddExports to read
additional modules or export additional packages. For example, if a
patch adds types to a new package then you could export that package
with -XaddExports. If the patch injects tests into an existing package
then those tests might have new dependences and requires compiling or
running with -XaddReads:$MODULE=junit for example.
This is how I thought that -Xpatch would work in short: the module-info in
src/main/java and src/test/java have both the same modulename. The
module-info in src/test/java specifies the extra required modules (like
junit). With -Xpatch the test-classes have access to the non-exported
main-classes too.
Post by Alan Bateman
-Alan
thanks,
Robert
Alan Bateman
2016-03-09 09:34:14 UTC
Permalink
Post by Robert Scholte
This is how I thought that -Xpatch would work in short: the
module-info in src/main/java and src/test/java have both the same
modulename. The module-info in src/test/java specifies the extra
required modules (like junit). With -Xpatch the test-classes have
access to the non-exported main-classes too.
If the sources in src/test/java are a completely separate module then
they will have their own module declaration.

If the tests are instead intended to augment the module, say where the
tests are in the same package as the code under test, they will not have
their own module declaration. This means no module-info.java in
src/test/java. As things currently stand then javac -Xmodule:$MODULE
will ignore the module-info.java when you compile the sources in
src/test/java. At run-time then you'll get a warning if there is a
module-info.class found when patching a module.

So I think you will need to get the module name when compiling the
tests. You should not need the module name when compiling the code in
src/main/java of course. The complication for the tests as they are
being compiled "as if" they are part of the module.

As the tests classes in the same module as the main classes then it
means the tests have access to all public types in the modules (no
exports are needed). Furthermore, they are in the same package as the
main classes then they have access to private package types/methods too.

The final part will be running the tests as the injected test classes
will have dependences on JUnit or TestNG tests. They module declaration
doesn't declare that it requires those and this is why we need to
augment it at run-time with -XaddReads so that it reads the JUnit
module. There are choices here as to whether JUnit is deployed on the
class path or module path, it can work as either.

-Alan
m***@oracle.com
2016-03-16 20:55:01 UTC
Permalink
Post by Robert Scholte
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
this description now in JEP 261 (http://openjdk.java.net/jeps/261):

As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in the
unnamed module, and at run time when the main class of the application is
loaded from the class path into the unnamed module.

This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.

- Mark
Robert Scholte
2016-03-17 19:51:32 UTC
Permalink
Hi,

it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.

Here's the compiler error:
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support

Let me quote Alan from one of the first responses on this thread:
"For the tests then I assume they are in the same packages as the sources
under src/main/java, is that right?

In that case I think you will want to compile the tests as if they are
part of the module:

javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...

where m is the module name and the module (with sources in src/main/java)
has already been compiled and then packaged as m.jar. The
-Xmodule:<module> option tells the compiler that you compiling the test
classes as if they are part of module m. There is no module-info.java in
the test tree."

To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it is
not solid enough.
And the next question would be: can Maven (or actually Plexus ClassWorld)
handle this?

I'll need to work out the things to be done and try to get more Maven
developers involved.

thanks,
Robert
Post by m***@oracle.com
Post by Robert Scholte
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in the
unnamed module, and at run time when the main class of the application is
loaded from the class path into the unnamed module.
This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.
- Mark
Alan Bateman
2016-03-17 20:23:25 UTC
Permalink
Post by Robert Scholte
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it
is not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more Maven
developers involved.
Would it you take it from the source module-info.class or the compiled
module-info.class? The former would require a small parser. The latter
is not difficult with ASM.

-Alan
Robert Scholte
2016-03-18 07:56:00 UTC
Permalink
Post by Alan Bateman
Post by Robert Scholte
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it
is not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more Maven
developers involved.
Would it you take it from the source module-info.class or the compiled
module-info.class? The former would require a small parser. The latter
is not difficult with ASM.
-Alan
I can do the former with QDox, for the latter I had JDK APIs in mind, but
if ASM is an option too, that's an interesting option. Need to figure out
how to do that.

Robert
Alan Bateman
2016-03-18 08:29:40 UTC
Permalink
Post by Robert Scholte
I can do the former with QDox, for the latter I had JDK APIs in mind,
but if ASM is an option too, that's an interesting option. Need to
figure out how to do that.
It should only be a few lines with ASM. If you have an input stream to
the module-info.class then ASM's ClassReader will give you the class
name in internal form and so easy to get the module name, this should do it:

ClassReader reader = new ClassReader(in);
String className = reader.getClassName();
int index = className.indexOf("/module-info");
if (index >= 1) {
String moduleName = className.substring(0, index).replace('/', '.');
}

Using the APIs will work too but if Maven is running on JDK 8 or older
then it won't be able to make use of the new Java SE 9 APIs.

-Alan.
Robert Scholte
2016-03-22 21:23:44 UTC
Permalink
Post by Robert Scholte
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Just wondering, is this the expected behavior?

DefaultProblemTest is on the *classpath* and I wouldn't expect that these
entries would have any effect on the modulepath entries. I would expect
that the packages between modules are checked, and that all these packages
are exposed to the classpath; no extra check if classpath packages are in
conflict with module packages.
The message says ' in *another* module', but this directory is not a
module, which makes it extra confusing.

thanks,
Robert
Post by Robert Scholte
Hi,
it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
"For the tests then I assume they are in the same packages as the
sources under src/main/java, is that right?
In that case I think you will want to compile the tests as if they are
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar. The
-Xmodule:<module> option tells the compiler that you compiling the test
classes as if they are part of module m. There is no module-info.java in
the test tree."
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it is
not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more Maven
developers involved.
thanks,
Robert
Post by m***@oracle.com
Post by Robert Scholte
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in the
unnamed module, and at run time when the main class of the
application is
loaded from the class path into the unnamed module.
This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.
- Mark
Richard Opalka
2016-03-22 22:29:09 UTC
Permalink
Hi,

I'm experiencing the same problem locally.
When trying to build Oracle provided maven artifact from sources, namely

http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar

the build fails on JDK9 (with Jigsaw) with message:

./src/javax/annotation/Priority.java:42: error: package exists in
another module: java.annotations.common
package javax.annotation;
^
1 error

How is Jigsaw javac going to deal with such compilation scenarios?

Rio
Post by Robert Scholte
Post by Robert Scholte
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Just wondering, is this the expected behavior?
DefaultProblemTest is on the *classpath* and I wouldn't expect that these
entries would have any effect on the modulepath entries. I would
expect that the packages between modules are checked, and that all
these packages are exposed to the classpath; no extra check if
classpath packages are in conflict with module packages.
The message says ' in *another* module', but this directory is not a
module, which makes it extra confusing.
thanks,
Robert
Post by Robert Scholte
Hi,
it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
"For the tests then I assume they are in the same packages as the
sources under src/main/java, is that right?
In that case I think you will want to compile the tests as if they
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar.
The -Xmodule:<module> option tells the compiler that you compiling
the test classes as if they are part of module m. There is no
module-info.java in the test tree."
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it
is not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more Maven
developers involved.
thanks,
Robert
Post by m***@oracle.com
Post by Robert Scholte
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in the
unnamed module, and at run time when the main class of the
application is
loaded from the class path into the unnamed module.
This change is in Jigsaw EA build #4647
(https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.
- Mark
Richard Opalka
2016-03-22 22:39:35 UTC
Permalink
Hi,

I just solved it by adding -Xmodule option:

javac -Xmodule:java.annotations.common -sourcepath src `find -type f
-name *.java`

Rio
Post by Richard Opalka
Hi,
I'm experiencing the same problem locally.
When trying to build Oracle provided maven artifact from sources, namely
http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar
./src/javax/annotation/Priority.java:42: error: package exists in
another module: java.annotations.common
package javax.annotation;
^
1 error
How is Jigsaw javac going to deal with such compilation scenarios?
Rio
Post by Robert Scholte
Post by Robert Scholte
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Just wondering, is this the expected behavior?
DefaultProblemTest is on the *classpath* and I wouldn't expect that these
entries would have any effect on the modulepath entries. I would
expect that the packages between modules are checked, and that all
these packages are exposed to the classpath; no extra check if
classpath packages are in conflict with module packages.
The message says ' in *another* module', but this directory is not a
module, which makes it extra confusing.
thanks,
Robert
On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte
Post by Robert Scholte
Hi,
it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
"For the tests then I assume they are in the same packages as the
sources under src/main/java, is that right?
In that case I think you will want to compile the tests as if they
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar.
The -Xmodule:<module> option tells the compiler that you compiling
the test classes as if they are part of module m. There is no
module-info.java in the test tree."
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but
it is not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more
Maven developers involved.
thanks,
Robert
Post by m***@oracle.com
Post by Robert Scholte
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in the
unnamed module, and at run time when the main class of the application is
loaded from the class path into the unnamed module.
This change is in Jigsaw EA build #4647
(https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.
- Mark
Alan Bateman
2016-03-23 07:55:50 UTC
Permalink
Post by Richard Opalka
Hi,
I'm experiencing the same problem locally.
When trying to build Oracle provided maven artifact from sources, namely
http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar
./src/javax/annotation/Priority.java:42: error: package exists in
another module: java.annotations.common
package javax.annotation;
^
1 error
How is Jigsaw javac going to deal with such compilation scenarios?
I've changed the subject line as this issue seems to be about how to
compile with, and make use of, the EE versions of the so-called "Common
Annotations".

The JSR 250 defined Common Annotations is one of a small number of APIs
that is shared between Java SE and Java EE. Java SE defines a subset,
where Java EE defines the full API (or the full set of annotations in
this case). With JDK 8 and older then Java EE or app servers needed to
deploy an EE version to override the Java SE version. The only supported
way of doing this was via the endorsed standards override mechanism
(that mechanism was documented for both endorsed standards and
standalone technologies with JSR 250 one of the standalone technologies).

As things currently stand, the replacement to the endorsed standards
override mechanism is upgradeable modules. In JEP 261 you will see the
option -upgrademodulepath that can be used to deploy modules that
upgrade/override modules in the JDK.

So what you need here is the Java EE version of the
java.annotations.common module and deploy it via -upgrademodulepath to
upgrade/override the module in the JDK.

Unfortunately there isn't an EE version of this module yet so you have
to create it yourself. Not hard, you just need to compile the following
module-info.java and put it in the top-level directory of the JAR file
to make it a modular JAR.

module java.annotations.common {
exports javax.annotation;
exports javax.annotation.security;
exports javax.annotation.sql;
}

Note that the Java SE/JDK version exports one package, the Java EE
version exports three packages.

You can check that the EE version is observable with the following common:

java -upgrademodulepath libs/javax.annotation-api.jar -listmods

or -listmods:java.annotations.common to have the module definition
printed so that you can checks the exports.

-Alan
Alan Bateman
2016-03-23 07:14:24 UTC
Permalink
Post by Robert Scholte
Post by Robert Scholte
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Just wondering, is this the expected behavior?
DefaultProblemTest is on the *classpath* and I wouldn't expect that these
entries would have any effect on the modulepath entries. I would
expect that the packages between modules are checked, and that all
these packages are exposed to the classpath; no extra check if
classpath packages are in conflict with module packages.
The message says ' in *another* module', but this directory is not a
module, which makes it extra confusing.
It looks like it is trying to compile
org/apache/maven/building/DefaultProblemTest.java on the class path
(unnamed module) but package org.apache.maven.building is in module
maven.builder.support on the module path.

I think this is back to needing the module name as this can only work if
you compile the test as if it is part of the module, meaning
-Xmodule:maven.builder.support here.

-Alan
Alan Bateman
2016-02-23 12:59:13 UTC
Permalink
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
Now it seems that I *must* add compile + test scoped to the
*classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
For the tests then I assume they are in the same packages as the sources
under src/main/java, is that right?

In that case I think you will want to compile the tests as if they are
part of the module:

javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...

where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar. The
-Xmodule:<module> option tells the compiler that you compiling the test
classes as if they are part of module m. There is no module-info.java in
the test tree.

Going further then I expect that JUnit or TestNG is also in the picture,
I assume the class path. In that case, the command becomes:

javac -Xmodule:m -d testclasses/m -mp m.jar \
-cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED \
test/java/...

where you are compiling test classes as if they are module m and at the
same time referencing JUnit types on the class path. The
-XaddReads:m=ALL-UNNAMED augments the module declaration to say that
module m reads all unnamed modules, just think class path here.


In order to run then you can use -Xpatch to augment the module with the
test classes:

java -Xpatch:testclasses -mp m.jar -cp junit-4.12.jar
-XaddReads:m=ALL-UNNAMED ...

It is as if the test classes are in m.jar. The alternative is of course
to add the test classes to the packaged module but you would still need
the -XaddReads because module m does not (and can not) declare that it
depends on types on the class path.


While on the topic then I should mention that we have a proposal coming
to support patches as JAR files as I'm sure you will get to the point
soon where the test classes are in a JAR file.

Hopefully the above is useful. I completely agree with Jon that we need
to put down detailed notes and examples. In the case of testing then we
have tried out the popular test frameworks on the class path (as above)
and also as modules. In the case of JUnit then we have been successful
with it on a the module path as an automatic module. Definitely
something to write up.

-Alan
Robert Scholte
2016-02-23 21:10:51 UTC
Permalink
Post by Alan Bateman
Post by Robert Scholte
Hi,
first of all I'd like to say that I'm very pleased with the new -mp
options, these matches better with the way Apache Maven would like to
work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/java and put all compile-scoped dependencies to the module
path, all compiles fines.
I assume that developers are less interested in adding a
module-info.java file to src/test/java, so that's what I'm doing right
now too.
Now it seems that I *must* add compile + test scoped to the *classpath*
to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the
modulepath and all test-scoped dependencies on the classpath, so the
modules keeps their inner related structure, but it seems that the
classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the
classpath is indeed the right approach in this case.
For the tests then I assume they are in the same packages as the sources
under src/main/java, is that right?
In that case I think you will want to compile the tests as if they are
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar. The
-Xmodule:<module> option tells the compiler that you compiling the test
classes as if they are part of module m. There is no module-info.java in
the test tree.
The related lifecycle phases of Maven are: compile, test-compile, test,
package.
So during test there's no m.jar yet, but target/classes or target/mods/m.
This shouldn't be an issue, though.

If I understand this correctly I need to know the module name. That is
information defined in the module-info, meaning I need to read that class
first. When possible I would like to avoid this. Suppose a developer has
made a syntax failure, I would hope that such error is thrown by javac,
not by Maven while doing some pre-compile actions on the source-files to
construct the correct commandline arguments.

I've already talked with Mark about the usage of -Xpatch, but that's
required if src/test/java is considered a module too.

And maybe this is the key question: if src/main/java is a module, should
we handle src/test/java as a module too or leave it as a classpath based
project?

thanks,
Robert
Post by Alan Bateman
Going further then I expect that JUnit or TestNG is also in the picture,
javac -Xmodule:m -d testclasses/m -mp m.jar \
-cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED \
test/java/...
where you are compiling test classes as if they are module m and at the
same time referencing JUnit types on the class path. The
-XaddReads:m=ALL-UNNAMED augments the module declaration to say that
module m reads all unnamed modules, just think class path here.
In order to run then you can use -Xpatch to augment the module with the
java -Xpatch:testclasses -mp m.jar -cp junit-4.12.jar
-XaddReads:m=ALL-UNNAMED ...
It is as if the test classes are in m.jar. The alternative is of course
to add the test classes to the packaged module but you would still need
the -XaddReads because module m does not (and can not) declare that it
depends on types on the class path.
While on the topic then I should mention that we have a proposal coming
to support patches as JAR files as I'm sure you will get to the point
soon where the test classes are in a JAR file.
Hopefully the above is useful. I completely agree with Jon that we need
to put down detailed notes and examples. In the case of testing then we
have tried out the popular test frameworks on the class path (as above)
and also as modules. In the case of JUnit then we have been successful
with it on a the module path as an automatic module. Definitely
something to write up.
-Alan
--
Using Opera's mail client: http://www.opera.com/mail/
Jonathan Gibbons
2016-02-23 21:20:39 UTC
Permalink
Post by Robert Scholte
And maybe this is the key question: if src/main/java is a module,
should we handle src/test/java as a module too or leave it as a
classpath based project?
thanks,
Robert
You list 2 choices, but there's 3 possible answers here.

If you're writing a test that only exercises the public/exported API of
the module, it could either be written as code in the unnamed module (a
"classpath based project"), or it could be written as a separate, named
module.

If your test is using the pattern of putting test classes in the same
package as that which is being tested, then the test has to be part of
the module being tested, which means you get into using -Xmodule at
compile time and -Xpatch at runtime.

-- Jon
Alan Bateman
2016-02-24 08:52:06 UTC
Permalink
Post by Robert Scholte
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the POM?
From the mails then it sounds like the project is mostly "unaware" that
it is creating a module. The other thing that comes to mind is the
source layout and whether it will get to the point where the module name
is in the file path. I'm mostly thinking of multi module projects where
one might have the source to multiple modules in the same source tree.

-Alan
Robert Scholte
2016-02-24 19:30:54 UTC
Permalink
Post by Alan Bateman
Post by Robert Scholte
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the POM?
From the mails then it sounds like the project is mostly "unaware" that
it is creating a module. The other thing that comes to mind is the
source layout and whether it will get to the point where the module name
is in the file path. I'm mostly thinking of multi module projects where
one might have the source to multiple modules in the same source tree.
-Alan
The name of the module with not end up in pom-4.0.0, it'll simply break
the xsd and would have effect on all other tools/IDEs/etc depending on the
pom.
The only place where one might specify the module name is in the
configuration of the maven-compiler-plugin.
In Brussels we talked about multimodules, but it makes more sense that 1
Maven project contains zero or one module-info[1].
And yes, I think a MavenProject will probably be unaware of its own module
name. It knows its source roots and outputdirectories (for both main/java
and test/java) and the packaged jar. Based on the availability of the
module-info in one of these locations it knows how to construct the
commandline arguments.
At least, this is what I'm hoping to achieve.

thanks,
Robert

[1] https://twitter.com/rfscholte/status/694599731515899904
Peter Levart
2016-03-22 12:06:05 UTC
Permalink
On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman
Post by Alan Bateman
Post by Robert Scholte
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the
POM? From the mails then it sounds like the project is mostly
"unaware" that it is creating a module. The other thing that comes to
mind is the source layout and whether it will get to the point where
the module name is in the file path. I'm mostly thinking of multi
module projects where one might have the source to multiple modules
in the same source tree.
-Alan
The name of the module with not end up in pom-4.0.0, it'll simply
break the xsd and would have effect on all other tools/IDEs/etc
depending on the pom.
The only place where one might specify the module name is in the
configuration of the maven-compiler-plugin.
In Brussels we talked about multimodules, but it makes more sense that
1 Maven project contains zero or one module-info[1].
And yes, I think a MavenProject will probably be unaware of its own
module name. It knows its source roots and outputdirectories (for both
main/java and test/java) and the packaged jar. Based on the
availability of the module-info in one of these locations it knows how
to construct the commandline arguments.
At least, this is what I'm hoping to achieve.
thanks,
Robert
[1] https://twitter.com/rfscholte/status/694599731515899904
Hi Robert,

Why do you want to support tests that "inject" classes into packages of
main artifact? Is this mainly because that's how it is done today? With
modules I would rather create tests in its own module and use qualified
exports from otherwise concealed packages of main module to give tests
access to types that are not accessible otherwise. This however means
that main module would have to use public qualifier on types and members
to allow test module to access them. In effect substituting the
package-private-nes with partly concealed packages to enable testability.

Perhaps jigsaw should realize that testabililty is an important aspect
to support. Forcing tools to compile a suitable set of javac and java
options to compile or inject new classes into an existing module and
augment it's dependencies is not very pleasant. Maybe this could be
supported with a little twist to the accessibility rules. Let me borrow
a rough idea that already circulated this list a while ago and modify it
to fit on the top of jigsaw accessibility rules.

Suppose that a qualified export of a package to the specific module(s)
could be augmented with say a "private" keyword:

module my.mod {
requires ...;
export private my.mod.internal to my.mod.test;
}

module my.mod.test {
requires my.mod;
requires junit;
}

...which would not only export the package to the specific module(s),
but also enable access to package-private types/members of that package
from the target module(s) as though those types/members were public for
them and for them only.

It would only be possible to specify "private" keyword with qualified
exports - not with unqualified.

Would that be against any jigsaw goals?

Regards, Peter
Robert Scholte
2016-03-22 21:16:50 UTC
Permalink
Post by Alex Buckley
On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman
Post by Alan Bateman
Post by Robert Scholte
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the
POM? From the mails then it sounds like the project is mostly
"unaware" that it is creating a module. The other thing that comes to
mind is the source layout and whether it will get to the point where
the module name is in the file path. I'm mostly thinking of multi
module projects where one might have the source to multiple modules in
the same source tree.
-Alan
The name of the module with not end up in pom-4.0.0, it'll simply break
the xsd and would have effect on all other tools/IDEs/etc depending on
the pom.
The only place where one might specify the module name is in the
configuration of the maven-compiler-plugin.
In Brussels we talked about multimodules, but it makes more sense that
1 Maven project contains zero or one module-info[1].
And yes, I think a MavenProject will probably be unaware of its own
module name. It knows its source roots and outputdirectories (for both
main/java and test/java) and the packaged jar. Based on the
availability of the module-info in one of these locations it knows how
to construct the commandline arguments.
At least, this is what I'm hoping to achieve.
thanks,
Robert
[1] https://twitter.com/rfscholte/status/694599731515899904
Hi Robert,
Why do you want to support tests that "inject" classes into packages of
main artifact? Is this mainly because that's how it is done today?
Yes, that's why. The success of modularization depends on the ease of
migration. Javac already comes with a lot of options and flags to make
this possible, it is Mavens task to set these with the right values. My
current opinion is that I don't want to force users to add module-info
files to the test sources, but the module structure of the main sources
should be respected.
If you want a separate module for testing, that's up to you. If people
want to patch the main module, that fine too. If javac supports it, then
Maven should support that too.

thanks,
Robert
Post by Alex Buckley
With modules I would rather create tests in its own module and use
qualified exports from otherwise concealed packages of main module to
give tests access to types that are not accessible otherwise. This
however means that main module would have to use public qualifier on
types and members to allow test module to access them. In effect
substituting the package-private-nes with partly concealed packages to
enable testability.
Perhaps jigsaw should realize that testabililty is an important aspect
to support. Forcing tools to compile a suitable set of javac and java
options to compile or inject new classes into an existing module and
augment it's dependencies is not very pleasant. Maybe this could be
supported with a little twist to the accessibility rules. Let me borrow
a rough idea that already circulated this list a while ago and modify it
to fit on the top of jigsaw accessibility rules.
Suppose that a qualified export of a package to the specific module(s)
module my.mod {
requires ...;
export private my.mod.internal to my.mod.test;
}
module my.mod.test {
requires my.mod;
requires junit;
}
...which would not only export the package to the specific module(s),
but also enable access to package-private types/members of that package
from the target module(s) as though those types/members were public for
them and for them only.
It would only be possible to specify "private" keyword with qualified
exports - not with unqualified.
Would that be against any jigsaw goals?
Regards, Peter
David M. Lloyd
2016-03-22 21:22:19 UTC
Permalink
Post by Alex Buckley
On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman
Post by Alan Bateman
Post by Robert Scholte
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the
POM? From the mails then it sounds like the project is mostly
"unaware" that it is creating a module. The other thing that comes to
mind is the source layout and whether it will get to the point where
the module name is in the file path. I'm mostly thinking of multi
module projects where one might have the source to multiple modules
in the same source tree.
-Alan
The name of the module with not end up in pom-4.0.0, it'll simply
break the xsd and would have effect on all other tools/IDEs/etc
depending on the pom.
The only place where one might specify the module name is in the
configuration of the maven-compiler-plugin.
In Brussels we talked about multimodules, but it makes more sense that
1 Maven project contains zero or one module-info[1].
And yes, I think a MavenProject will probably be unaware of its own
module name. It knows its source roots and outputdirectories (for both
main/java and test/java) and the packaged jar. Based on the
availability of the module-info in one of these locations it knows how
to construct the commandline arguments.
At least, this is what I'm hoping to achieve.
thanks,
Robert
[1] https://twitter.com/rfscholte/status/694599731515899904
Hi Robert,
Why do you want to support tests that "inject" classes into packages of
main artifact? Is this mainly because that's how it is done today? With
modules I would rather create tests in its own module and use qualified
exports from otherwise concealed packages of main module to give tests
access to types that are not accessible otherwise. This however means
that main module would have to use public qualifier on types and members
to allow test module to access them. In effect substituting the
package-private-nes with partly concealed packages to enable testability.
Perhaps jigsaw should realize that testabililty is an important aspect
to support. Forcing tools to compile a suitable set of javac and java
options to compile or inject new classes into an existing module and
augment it's dependencies is not very pleasant. Maybe this could be
supported with a little twist to the accessibility rules. Let me borrow
a rough idea that already circulated this list a while ago and modify it
to fit on the top of jigsaw accessibility rules.
Suppose that a qualified export of a package to the specific module(s)
module my.mod {
requires ...;
export private my.mod.internal to my.mod.test;
}
module my.mod.test {
requires my.mod;
requires junit;
}
...which would not only export the package to the specific module(s),
but also enable access to package-private types/members of that package
from the target module(s) as though those types/members were public for
them and for them only.
FWIW This is something I've been asking for in the JPMS EG. I think
this would be an incredibly powerful and useful security tool... and
could also potentially eliminate lots of "shared secrets" from the JDK
code base (and a few others as well). Not just for tests but also for
other existing code bases which today have to rely on
privacy-by-convention/documentation for this kind of sharing.
Post by Alex Buckley
It would only be possible to specify "private" keyword with qualified
exports - not with unqualified.
Would that be against any jigsaw goals?
Regards, Peter
--
- DML
Russell Gold
2016-03-22 22:20:52 UTC
Permalink
I’d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should.

I am assuming:

1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well.
2) the artifact type “module” (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path)
3) the classes being built may be put into their own module, but might not be.

Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing.
The test-compile step needs to handle all four, including the compiled class in its test class path.

Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies.

Did I completely miss the point?

- Russ
Hi,
first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and class-folders.
Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped dependencies to the module path, all compiles fines.
I assume that developers are less interested in adding a module-info.java file to src/test/java, so that's what I'm doing right now too.
Now it seems that I *must* add compile + test scoped to the *classpath* to be able to compile the test classes.
My first approach was to leave the compile-scoped dependencies on the modulepath and all test-scoped dependencies on the classpath, so the modules keeps their inner related structure, but it seems that the classpath classes cannot access the modulepath classes.
I'm looking for the confirmation that putting all dependencies on the classpath is indeed the right approach in this case.
For the tests then I assume they are in the same packages as the sources under src/main/java, is that right?
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in src/main/java) has already been compiled and then packaged as m.jar. The -Xmodule:<module> option tells the compiler that you compiling the test classes as if they are part of module m. There is no module-info.java in the test tree.
javac -Xmodule:m -d testclasses/m -mp m.jar \
-cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED \
test/java/...
where you are compiling test classes as if they are module m and at the same time referencing JUnit types on the class path. The -XaddReads:m=ALL-UNNAMED augments the module declaration to say that module m reads all unnamed modules, just think class path here.
java -Xpatch:testclasses -mp m.jar -cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED ...
It is as if the test classes are in m.jar. The alternative is of course to add the test classes to the packaged module but you would still need the -XaddReads because module m does not (and can not) declare that it depends on types on the class path.
While on the topic then I should mention that we have a proposal coming to support patches as JAR files as I'm sure you will get to the point soon where the test classes are in a JAR file.
Hopefully the above is useful. I completely agree with Jon that we need to put down detailed notes and examples. In the case of testing then we have tried out the popular test frameworks on the class path (as above) and also as modules. In the case of JUnit then we have been successful with it on a the module path as an automatic module. Definitely something to write up.
-Alan
Alan Bateman
2016-03-23 07:21:46 UTC
Permalink
Post by Russell Gold
I’d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should.
1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well.
2) the artifact type “module” (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path)
3) the classes being built may be put into their own module, but might not be.
Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing.
The test-compile step needs to handle all four, including the compiled class in its test class path.
Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies.
Did I completely miss the point?
It depends on where the tests live. If they are black box tests that
only exercise the API (the public types in the module's exported
packages) then they can live anywhere. If they are in the same class
loader and package as the code they are testing (the norm in Maven) then
they need to compiled as if they are part of the module. We might think
of these as white box tests as they can make use of public types in
packages that aren't exported, maybe they are using package-private
types/methods too.

-Alan
Stephen Colebourne
2016-03-23 11:01:00 UTC
Permalink
If they are in the same class loader and package as
the code they are testing (the norm in Maven) then they need to compiled as
if they are part of the module.
I struggle with that idea.

To me, tests are very definitely not part of the module. To me, they
are very clearly a separate module, one that uses the base module
(separate tree of code, separate dependencies, separate compilation
phase). In maven, there is even the possibility for one testing module
to depend on another testing module, a very useful feature.

The only special case about testing modules is that they are given
full access to everything in the underlying module. Forcing test code
to be embedded within the actual module just because the module design
doesn't allow any other option is flawed IMO.

Peter Levart's mail suggested one approach to provide the necessary
access rights for testing modules. But it still requires publication
package-by-package. Really, what is needed is a way to express that
the testing module is intimately connected, perhaps imposing a
requirement that both are loaded in the same classloader. eg.

module my.mod {
fully-exposed-to my.mod.test;
}
module my.mod.test {
requires my.mod; // since other end specifies fully-exposed-to,
this gets full access
requires junit;
}

Is this issue on the list of open issues?
http://openjdk.java.net/projects/jigsaw/spec/issues/

Stephen
David Hill
2016-03-23 12:28:27 UTC
Permalink
Post by Stephen Colebourne
If they are in the same class loader and package as
the code they are testing (the norm in Maven) then they need to compiled as
if they are part of the module.
We have worked through this white/black box testing classes in JavaFX, While not a perfect solution we have something that seems to work (at least we get the tests to pass anyway :-)

I created a OpenJFX Unit test in Jigsaw TOI in our wiki here <https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests>. While it is specific to the JFX build, there is a lot of detail in there that is general to unit testing and Jigsaw.

There are several keys here.
1) separate out the white/black box test classes, creating new "shims" (white box classes) as needed. We picked the "test.*" package for the black box tests and refactored all of our unit tests into it.
2) at build time create a copy of our "core" classes with the white box shims added in so that we have one module override tree
3) use Xpatch, @addExports so that things can be found

"@addExport" is an argfile usage which makes adding multiline -XaddExport: options reasonable. If you don't know about @argfile, you might want to look at my wiki page just to learn about those :-)

Certainly the solution we have took a lot of rework, and we did debate with the Jigsaw team about several elements of it. But what we ended up with works within the current boundaries.

BTW - any feedback or questions on the TOI would be appreciated.

https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests
Post by Stephen Colebourne
I struggle with that idea.
To me, tests are very definitely not part of the module. To me, they
are very clearly a separate module, one that uses the base module
(separate tree of code, separate dependencies, separate compilation
phase). In maven, there is even the possibility for one testing module
to depend on another testing module, a very useful feature.
The only special case about testing modules is that they are given
full access to everything in the underlying module. Forcing test code
to be embedded within the actual module just because the module design
doesn't allow any other option is flawed IMO.
Peter Levart's mail suggested one approach to provide the necessary
access rights for testing modules. But it still requires publication
package-by-package. Really, what is needed is a way to express that
the testing module is intimately connected, perhaps imposing a
requirement that both are loaded in the same classloader. eg.
module my.mod {
fully-exposed-to my.mod.test;
}
module my.mod.test {
requires my.mod; // since other end specifies fully-exposed-to,
this gets full access
requires junit;
}
Is this issue on the list of open issues?
http://openjdk.java.net/projects/jigsaw/spec/issues/
Stephen
--
David Hill<***@Oracle.com>
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the world."
-- George Santayana (1863 - 1952)
Alan Bateman
2016-03-23 12:51:24 UTC
Permalink
Post by Stephen Colebourne
If they are in the same class loader and package as
the code they are testing (the norm in Maven) then they need to compiled as
if they are part of the module.
I struggle with that idea.
If types T1 and T2 have the same defining loader and both types are in
the same package then they are in the same module. T1 can't be module M1
and T2 in a different module M2.

(I shudder the thought of it being different or attempting to change
what default/package access means after all these years.)
Post by Stephen Colebourne
To me, tests are very definitely not part of the module. To me, they
are very clearly a separate module, one that uses the base module
(separate tree of code, separate dependencies, separate compilation
phase). In maven, there is even the possibility for one testing module
to depend on another testing module, a very useful feature.
You can of course develop tests in their own modules, this should be
painless for black-box testing.

White-box testing is more complicated of course as such tests need to
nestmate with the module internals they are testing. If people are
testing package private classes or methods today then those test classes
are in the same loader/package as the code they are testing. There are
several discussions points in the mails here but I believe it is the
scenario that Robert is trying to get working with Maven. It seems more
of a convention though, it may be that many tests aren't really white
tests and they could like in their own test.* packages and other modules
without difficulty.
Post by Stephen Colebourne
The only special case about testing modules is that they are given
full access to everything in the underlying module. Forcing test code
to be embedded within the actual module just because the module design
doesn't allow any other option is flawed IMO.
There isn't anything forcing the test sources to be the same source tree
as the classes they are testing. Tests that directly make use of module
internals can be compiled separately, have dependences beyond what the
original module requires, and be packaged in their own artifact. When
running then the -Xpatch option brings them together. If the tools can
make this easy for average developers then it might not be too bad.

-Alan.
Stephen Colebourne
2016-03-23 14:42:58 UTC
Permalink
If types T1 and T2 have the same defining loader and both types are in the
same package then they are in the same module. T1 can't be module M1 and T2
in a different module M2.
(I shudder the thought of it being different or attempting to change what
default/package access means after all these years.)
I'm not asking for package scope to change meaning. It is Jigsaw that
is trying to change its meaning wrt tests.

Discussion of white vs black box testing is all very well and good,
but its completely impractical. There are tens of thousands of
existing projects out there, in open source and private, that rely on
tests being in the same package. It is in essence a fundamental part
of common approaches to testing. Making it hard to test code in the
same package, as seems to be proposed, would be a nightmare for
migration. (Many open source projects are for fun in spare time. Who
is going to want to refactor all their tests to meet what amounts to
an artificial limitation? Not me.)

I don't particularly care what the mechanism is for this, but at the
requirements level:
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module

To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.

One apparent option would appear to be to merge the two modules
dynamically at load time. However, they do need to be released and
published separately (Note that I view the thread discussion of
references to test classes on the classpath as another hack. The
release and dependency elements clearly show tests to be modules, just
ones with special access.)

Stephen
Alan Bateman
2016-03-23 15:18:50 UTC
Permalink
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.

In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.

-Alan
Remi Forax
2016-03-28 10:13:47 UTC
Permalink
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.

I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.

So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.

So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.

Rémi

----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Ali Ebrahimi
2016-03-28 12:55:48 UTC
Permalink
I think we can adapt OSGI fragment bundle here and introduce module
fragments that is attached to a host module.

So we would have test fragment that is embeded in main module. So we would
have one module.
What do you think?
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as
different modules can be attractive because everything seems to be put at
the right place but there is a big drawback. Because modules are reified at
runtime, it means that the runtime environment of the tests will be
different from the production environment.
So as Alan said, from the jigsaw point of view at runtime, the tests and
the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as one
module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
--
Best Regards,
Ali Ebrahimi
Stephen Felts
2016-03-28 14:23:09 UTC
Permalink
Having spent 3 years using OSGI, fragment bundles were a great feature that we used to overcome this type of problem and others.
I like the idea but I don't think it will be popular in Jigsaw (and OSGI is a four-letter word).



-----Original Message-----
From: Ali Ebrahimi [mailto:***@gmail.com]
Sent: Monday, March 28, 2016 8:56 AM
To: Remi Forax
Cc: jigsaw-dev
Subject: Re: modulepath and classpath mixture

I think we can adapt OSGI fragment bundle here and introduce module fragments that is attached to a host module.

So we would have test fragment that is embeded in main module. So we would have one module.
What do you think?
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as different modules can be attractive because everything seems to be
put at the right place but there is a big drawback. Because modules
are reified at runtime, it means that the runtime environment of the
tests will be different from the production environment.
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them
as one module, maybe javac should help by providing a way to merge 2
module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the main module
- the test module needs to be able to invoke package-scoped code
in the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test
where B depends on A. Module A-test may have a method foo() that
uses package scope to access something in A. Module B-test will
depend on A-test and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they are instead compiled and run in a way that patches the main
module. The second difference is that they don't have their own
module declaration, instead the compilation or run augments the
dependences with any additional dependences that the tests have. As
I said, if they tools makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of references to test
classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
--
Best Regards,
Ali Ebrahimi
Paul Benedict
2016-03-28 17:21:09 UTC
Permalink
Stephen C, I'd like to question the assumption why tests must be their own
module? Clearly tests are going to be their own artifact, but I am not sure
they need the semantics of module boundaries. Placing on them classpath
would be the best thing for them, I think. However, two requirements would
still need to be met:

(a) Split packages need to be allowed so test classes can live in the same
package as the main classes
(b) Test classes can replace main classes

The patch/override command line argument already satisfies (b). Regarding
(a), although the classpath exports everything, code in an named module
can't access types in the unnamed module. That will be necessary so
existing code in "main" can access the replacement classes in "test".

If there was a mechanism to allow classpath code to overlay with module
code, existing Maven projects could function normally.

Cheers,
Paul
Post by Stephen Felts
Having spent 3 years using OSGI, fragment bundles were a great feature
that we used to overcome this type of problem and others.
I like the idea but I don't think it will be popular in Jigsaw (and OSGI
is a four-letter word).
-----Original Message-----
Sent: Monday, March 28, 2016 8:56 AM
To: Remi Forax
Cc: jigsaw-dev
Subject: Re: modulepath and classpath mixture
I think we can adapt OSGI fragment bundle here and introduce module
fragments that is attached to a host module.
So we would have test fragment that is embeded in main module. So we would have one module.
What do you think?
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as different modules can be attractive because everything seems to be
put at the right place but there is a big drawback. Because modules
are reified at runtime, it means that the runtime environment of the
tests will be different from the production environment.
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them
as one module, maybe javac should help by providing a way to merge 2
module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the main module
- the test module needs to be able to invoke package-scoped code
in the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test
where B depends on A. Module A-test may have a method foo() that
uses package scope to access something in A. Module B-test will
depend on A-test and rely on foo() to get access to that internal
object.
Post by Remi Forax
To your list, I would add the ability to make use of testing
frameworks like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they are instead compiled and run in a way that patches the main
module. The second difference is that they don't have their own
module declaration, instead the compilation or run augments the
dependences with any additional dependences that the tests have. As
I said, if they tools makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of references to test
classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
--
Best Regards,
Ali Ebrahimi
Stephen Felts
2016-03-29 16:33:22 UTC
Permalink
Here’s an interesting problem.

 

I have a lot of JDK9-specific command line options.

I decided to try to put them into an argsfile.

I then tried to use the @argsfile in a gradle script using something like

 

options.compilerArgs=’@/argsfile’

 

I was getting a ‘javac: invalid flag: @/argsfile’ and couldn’t figure out why.

The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile.

 

 

 

 
Stephen Felts
2016-03-29 16:37:16 UTC
Permalink
For you gradle experts, the syntax below is obviously wrong.

options.compilerArgs << '@/argsfile'

Maybe we can get the gradle folks to recognize @filename and expand it into their argsfile?


-----Original Message-----
From: Stephen Felts
Sent: Tuesday, March 29, 2016 12:33 PM
To: jigsaw-dev
Subject: argsfile problem

Here’s an interesting problem.

 

I have a lot of JDK9-specific command line options.

I decided to try to put them into an argsfile.

I then tried to use the @argsfile in a gradle script using something like

 

options.compilerArgs=’@/argsfile’

 

I was getting a ‘javac: invalid flag: @/argsfile’ and couldn’t figure out why.

The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile.

 

 

 

 
Stephen Colebourne
2016-03-29 13:24:15 UTC
Permalink
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.

Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).

Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.

Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Remi Forax
2016-03-29 15:41:38 UTC
Permalink
----- Mail original -----
Envoyé: Mardi 29 Mars 2016 15:24:15
Objet: Re: modulepath and classpath mixture
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as
different modules can be attractive because everything seems to be put at
the right place but there is a big drawback. Because modules are reified
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
yes, you just want your tests to run in a runtime which is as close as possible to the runtime of the production environment.
It's like when a test fails because JUnit calls the test concurrently when in production the code always run under a giant lock.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
You also need to support split packages or a kind of export...to that allows to export package private method as public.
These are two major deviations from the jigsaw canon.

Instead of considering tests as a separated module, i prefer to consider them as a separated version (1.0 vs 1.0-test),
the test version includes the code, the tests, and have several more dependencies on JUnit like modules.
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
We agree that a module = deployment-artifact-with-dependencies, but we disagree because for me the test should be a module with the same name but a different version (by example with a test suffix) while you think it should be a different module.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
I don't think the classpath will die but if you want to use things like jlink, it will not work if you have jars in the a classpath.

Rémi
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and
the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as
one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Paul Benedict
2016-03-29 15:55:10 UTC
Permalink
Remi, it's really untenable to give tests a different version. Tests are
currently built under the same version as the main project under one master
parent project. Split packages are still going to be a necessary because
that's the world of thousands of existing projects. So that might be
against jigsaw canon but hopefully a compromise can be found.

Cheers,
Paul
Post by Remi Forax
----- Mail original -----
Envoyé: Mardi 29 Mars 2016 15:24:15
Objet: Re: modulepath and classpath mixture
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as
Post by Remi Forax
different modules can be attractive because everything seems to be put
at
Post by Remi Forax
the right place but there is a big drawback. Because modules are
reified
Post by Remi Forax
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
yes, you just want your tests to run in a runtime which is as close as
possible to the runtime of the production environment.
It's like when a test fails because JUnit calls the test concurrently when
in production the code always run under a giant lock.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
You also need to support split packages or a kind of export...to that
allows to export package private method as public.
These are two major deviations from the jigsaw canon.
Instead of considering tests as a separated module, i prefer to consider
them as a separated version (1.0 vs 1.0-test),
the test version includes the code, the tests, and have several more
dependencies on JUnit like modules.
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
We agree that a module = deployment-artifact-with-dependencies, but we
disagree because for me the test should be a module with the same name but
a different version (by example with a test suffix) while you think it
should be a different module.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
I don't think the classpath will die but if you want to use things like
jlink, it will not work if you have jars in the a classpath.
Rémi
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and
Post by Remi Forax
the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as
one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the
Post by Remi Forax
Post by Stephen Colebourne
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test
where B
Post by Remi Forax
Post by Stephen Colebourne
depends on A. Module A-test may have a method foo() that uses
package
Post by Remi Forax
Post by Stephen Colebourne
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks
Post by Remi Forax
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Remi Forax
are instead compiled and run in a way that patches the main module.
The
Post by Remi Forax
second difference is that they don't have their own module
declaration,
Post by Remi Forax
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
f***@univ-mlv.fr
2016-03-29 16:10:38 UTC
Permalink
Paul,
you can give a different version to your module but you don't have to.
Test can use the very same module name along with the same version.

Rémi

----- Mail original -----
Envoyé: Mardi 29 Mars 2016 17:55:10
Objet: Re: modulepath and classpath mixture
Remi, it's really untenable to give tests a different version. Tests are
currently built under the same version as the main project under one master
parent project. Split packages are still going to be a necessary because
that's the world of thousands of existing projects. So that might be against
jigsaw canon but hopefully a compromise can be found.
Cheers,
Paul
Post by Remi Forax
----- Mail original -----
Envoyé: Mardi 29 Mars 2016 15:24:15
Objet: Re: modulepath and classpath mixture
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as
different modules can be attractive because everything seems to be put at
the right place but there is a big drawback. Because modules are reified
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
yes, you just want your tests to run in a runtime which is as close as
possible to the runtime of the production environment.
It's like when a test fails because JUnit calls the test concurrently when
in
production the code always run under a giant lock.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
You also need to support split packages or a kind of export...to that
allows
to export package private method as public.
These are two major deviations from the jigsaw canon.
Instead of considering tests as a separated module, i prefer to consider
them
as a separated version (1.0 vs 1.0-test),
the test version includes the code, the tests, and have several more
dependencies on JUnit like modules.
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
We agree that a module = deployment-artifact-with-dependencies, but we
disagree because for me the test should be a module with the same name but
a
different version (by example with a test suffix) while you think it should
be a different module.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
I don't think the classpath will die but if you want to use things like
jlink, it will not work if you have jars in the a classpath.
Rémi
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and
the code should be in the same module.
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as
one module,
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Russell Gold
2016-03-29 16:33:55 UTC
Permalink
Hi Stephen,

Why do you need any kind of friend access?

It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all.

I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path!

- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Paul Benedict
2016-03-30 02:47:11 UTC
Permalink
Russell, when you drop a jar on the classpath, module code will not be able
to access it in a split package situation. That's the big barrier here.
Maven test projects are typically written with the same package shared with
the "main" code.

Cheers,
Paul
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The
tests can simply run with the production code on the class path, and then
there are no module issues at all.
I think a larger problem is that you can do what I just said with the
jars, even a jar which has been designated as a module by virtue of having
a module-info.class in it. That means that, when users are up taking jars,
they are not prevented from accessing module internals. They can put the
jars on the module path, of course, but they can still use them on the
class path!
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as different modules can be attractive because everything seems to be put
at the right place but there is a big drawback. Because modules are reified
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
Post by Stephen Colebourne
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
Post by Stephen Colebourne
Post by Remi Forax
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as one
module,
Post by Stephen Colebourne
Post by Remi Forax
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Post by Stephen Colebourne
Post by Remi Forax
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Stephen Colebourne
Post by Remi Forax
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Russell Gold
2016-03-30 12:28:36 UTC
Permalink
Hi Paul,

Could you explain? What kind of code do you mean cannot access it? And what do you mean by “a split package situation”?
Post by Russell Gold
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part of the unnamed module
Yes
So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another.

- Russ
Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code.
Cheers,
Paul
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all.
I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path!
- Russ
Post by Russell Gold
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Alan Bateman
2016-03-30 13:45:03 UTC
Permalink
Post by Russell Gold
So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another.
There shouldn't any issue there, it should just work as it has always done.

The thread here has meandered a bit but I think the scenario under
discussion is tests for a module that need to nestmate with the module
under test. The tests are in their own test tree. The tests are compiled
separately from the module they test and may have additional dependences
(such as on TestNG or JUnit for example). When compiling or running then
the tests need to access public types in non-exported packages and maybe
package private members too. The support for this has been in jake for a
long time but involves command line options that many developers or
build environments won't immediately grok. In particular the tests have
to be compiled "as if" they augment the already compiled module - that
is what javac -Xmodule is about. There is no need to co-locate source
files or class files of course. When run then the -Xpatch option is what
brings the tests and the module classes together. If we get the tools
right then most developers won't ever see this of course.

One other thing to say that we've already been through some of this with
the JDK tests. The jtreg test harness that we use for the JDK tests has
been updated (thanks to Jon Gibbons) with useful support for modules
[1]. It's enough for us to write tests that use JDK-internal APIs or
write tests that nestmate with types in system modules so that they get
access to package private type or public types in non-exported packages.
It has rudimentary support for user modules too. Additional dependences
are still an issue but our tests don't require additional dependences
beyond TestNG. The test harness employs a bit of hackery to get things
done, important when starting out, but I expect will go away in time.

-Alan.

[1]
http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
Stephen Colebourne
2016-03-30 14:03:38 UTC
Permalink
Post by Alan Bateman
The thread here has meandered a bit but I think the scenario under
discussion is tests for a module that need to nestmate with the module under
test. The tests are in their own test tree. The tests are compiled
separately from the module they test and may have additional dependences
(such as on TestNG or JUnit for example). When compiling or running then the
tests need to access public types in non-exported packages and maybe package
private members too.
Yes, plus there is a need for one set of tests to depend on another
set of tests - ie. tests can be an artifact.
Post by Alan Bateman
The support for this has been in jake for a long time
but involves command line options that many developers or build environments
won't immediately grok. In particular the tests have to be compiled "as if"
they augment the already compiled module - that is what javac -Xmodule is
about. There is no need to co-locate source files or class files of course.
When run then the -Xpatch option is what brings the tests and the module
classes together. If we get the tools right then most developers won't ever
see this of course.
This is perhaps a solution that works, but it comes across as highly
esoteric. Two different command line flags, augmenting/patching
modules. What I see is a nightmare to explain.

And while tools can make things easy, it is inadvisable for the design
for running something as basic as tests to be so complex that it
cannot practically be done without tools.

What I see as a better solution is the same approach as I argued for
with optional dependencies - enhancing the syntax of module-info.java
to avoid the need for command line flags

Stephen
Remi Forax
2016-03-30 14:12:59 UTC
Permalink
Alan, Jon,
i think javac -Xmodule should merge the module-info.java from the existing module and the one declared in the directory,
with the current semantics of the module-info, merging of modules is easy and with no corner cases,
so for testing, the test will be able to declare their own dependencies inside their own module-info.java.

Proposed semantics for merging,
- do the union of the required modules
- if one required module is required publicly, it will be required publicly.
- do the union of the exported packages
- if one exported package is restricted, do the union of the restriction
- do the union of the uses.
- do the union of the provides.

so merging two modules is symmetric and will always succeed.

Rémi

----- Mail original -----
Envoyé: Mercredi 30 Mars 2016 15:45:03
Objet: Re: modulepath and classpath mixture
Post by Russell Gold
So if the tests and main code are both in directories, which they have been
up to now in Maven, why would there be a problem? Both would be in the
unnamed module and able to access one another.
There shouldn't any issue there, it should just work as it has always done.
The thread here has meandered a bit but I think the scenario under
discussion is tests for a module that need to nestmate with the module
under test. The tests are in their own test tree. The tests are compiled
separately from the module they test and may have additional dependences
(such as on TestNG or JUnit for example). When compiling or running then
the tests need to access public types in non-exported packages and maybe
package private members too. The support for this has been in jake for a
long time but involves command line options that many developers or
build environments won't immediately grok. In particular the tests have
to be compiled "as if" they augment the already compiled module - that
is what javac -Xmodule is about. There is no need to co-locate source
files or class files of course. When run then the -Xpatch option is what
brings the tests and the module classes together. If we get the tools
right then most developers won't ever see this of course.
One other thing to say that we've already been through some of this with
the JDK tests. The jtreg test harness that we use for the JDK tests has
been updated (thanks to Jon Gibbons) with useful support for modules
[1]. It's enough for us to write tests that use JDK-internal APIs or
write tests that nestmate with types in system modules so that they get
access to package private type or public types in non-exported packages.
It has rudimentary support for user modules too. Additional dependences
are still an issue but our tests don't require additional dependences
beyond TestNG. The test harness employs a bit of hackery to get things
done, important when starting out, but I expect will go away in time.
-Alan.
[1]
http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
Ali Ebrahimi
2016-03-30 15:12:22 UTC
Permalink
So, do you suggest partial modules or module fragments?

Why we make things so complex for writing single test method. I think
testing is an essential part of development, so modular java should have
first class support for that.
I don't see command line options as developer friendly solution, even
things gets worse when have dozen of modules.
Post by Remi Forax
Alan, Jon,
i think javac -Xmodule should merge the module-info.java from the existing
module and the one declared in the directory,
with the current semantics of the module-info, merging of modules is easy
and with no corner cases,
so for testing, the test will be able to declare their own dependencies
inside their own module-info.java.
Proposed semantics for merging,
- do the union of the required modules
- if one required module is required publicly, it will be required publicly.
- do the union of the exported packages
- if one exported package is restricted, do the union of the restriction
- do the union of the uses.
- do the union of the provides.
so merging two modules is symmetric and will always succeed.
Rémi
----- Mail original -----
Envoyé: Mercredi 30 Mars 2016 15:45:03
Objet: Re: modulepath and classpath mixture
Post by Russell Gold
So if the tests and main code are both in directories, which they have
been
Post by Russell Gold
up to now in Maven, why would there be a problem? Both would be in the
unnamed module and able to access one another.
There shouldn't any issue there, it should just work as it has always
done.
The thread here has meandered a bit but I think the scenario under
discussion is tests for a module that need to nestmate with the module
under test. The tests are in their own test tree. The tests are compiled
separately from the module they test and may have additional dependences
(such as on TestNG or JUnit for example). When compiling or running then
the tests need to access public types in non-exported packages and maybe
package private members too. The support for this has been in jake for a
long time but involves command line options that many developers or
build environments won't immediately grok. In particular the tests have
to be compiled "as if" they augment the already compiled module - that
is what javac -Xmodule is about. There is no need to co-locate source
files or class files of course. When run then the -Xpatch option is what
brings the tests and the module classes together. If we get the tools
right then most developers won't ever see this of course.
One other thing to say that we've already been through some of this with
the JDK tests. The jtreg test harness that we use for the JDK tests has
been updated (thanks to Jon Gibbons) with useful support for modules
[1]. It's enough for us to write tests that use JDK-internal APIs or
write tests that nestmate with types in system modules so that they get
access to package private type or public types in non-exported packages.
It has rudimentary support for user modules too. Additional dependences
are still an issue but our tests don't require additional dependences
beyond TestNG. The test harness employs a bit of hackery to get things
done, important when starting out, but I expect will go away in time.
-Alan.
[1]
http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
--
Best Regards,
Ali Ebrahimi
f***@univ-mlv.fr
2016-03-30 21:45:41 UTC
Permalink
----- Mail original -----
Envoyé: Mercredi 30 Mars 2016 17:12:22
Objet: Re: modulepath and classpath mixture
So, do you suggest partial modules or module fragments?
A kind of exploded module with sources available in more than one directory.
Classes are still in one modular jar with one module-info.class (so at runtime, there is only one module).
Why we make things so complex for writing single test method. I think testing
is an essential part of development, so modular java should have first class
support for that.
I don't see command line options as developer friendly solution, even things
gets worse when have dozen of modules.
That's another question, i think we first need to agree that we just want to have the main code and the test code into different directory and then we can see if javac -Xmodule is the best syntax or if by example -modulesourcepath can accept to have several directories that describe the same module.

cheers,
Rémi
Post by Remi Forax
Alan, Jon,
i think javac -Xmodule should merge the module-info.java from the existing
module and the one declared in the directory,
with the current semantics of the module-info, merging of modules is easy
and
with no corner cases,
so for testing, the test will be able to declare their own dependencies
inside their own module-info.java.
Proposed semantics for merging,
- do the union of the required modules
- if one required module is required publicly, it will be required publicly.
- do the union of the exported packages
- if one exported package is restricted, do the union of the restriction
- do the union of the uses.
- do the union of the provides.
so merging two modules is symmetric and will always succeed.
Rémi
----- Mail original -----
Envoyé: Mercredi 30 Mars 2016 15:45:03
Objet: Re: modulepath and classpath mixture
Post by Russell Gold
So if the tests and main code are both in directories, which they have been
up to now in Maven, why would there be a problem? Both would be in the
unnamed module and able to access one another.
There shouldn't any issue there, it should just work as it has always done.
The thread here has meandered a bit but I think the scenario under
discussion is tests for a module that need to nestmate with the module
under test. The tests are in their own test tree. The tests are compiled
separately from the module they test and may have additional dependences
(such as on TestNG or JUnit for example). When compiling or running then
the tests need to access public types in non-exported packages and maybe
package private members too. The support for this has been in jake for a
long time but involves command line options that many developers or
build environments won't immediately grok. In particular the tests have
to be compiled "as if" they augment the already compiled module - that
is what javac -Xmodule is about. There is no need to co-locate source
files or class files of course. When run then the -Xpatch option is what
brings the tests and the module classes together. If we get the tools
right then most developers won't ever see this of course.
One other thing to say that we've already been through some of this with
the JDK tests. The jtreg test harness that we use for the JDK tests has
been updated (thanks to Jon Gibbons) with useful support for modules
[1]. It's enough for us to write tests that use JDK-internal APIs or
write tests that nestmate with types in system modules so that they get
access to package private type or public types in non-exported packages.
It has rudimentary support for user modules too. Additional dependences
are still an issue but our tests don't require additional dependences
beyond TestNG. The test harness employs a bit of hackery to get things
done, important when starting out, but I expect will go away in time.
-Alan.
[1]
http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
--
Best Regards,
Ali Ebrahimi
Jonathan Gibbons
2016-03-31 00:10:29 UTC
Permalink
------------------------------------------------------------------------
*Envoyé: *Mercredi 30 Mars 2016 17:12:22
*Objet: *Re: modulepath and classpath mixture
So, do you suggest partial modules or module fragments?
A kind of exploded module with sources available in more than one directory.
Classes are still in one modular jar with one module-info.class (so at
runtime, there is only one module).
Why we make things so complex for writing single test method. I
think testing is an essential part of development, so modular java
should have first class support for that.
I don't see command line options as developer friendly solution,
even things gets worse when have dozen of modules.
That's another question, i think we first need to agree that we just
want to have the main code and the test code into different directory
and then we can see if javac -Xmodule is the best syntax or if by
example -modulesourcepath can accept to have several directories that
describe the same module.
-modulesourcepath can accept several source directories that together
comprise the source for a single module. If nothing else, you can see
this utilized in the JDK build, where the source structure for a module
may contain subdirectories for platform-independent classes,
platform-specific classes, and dynamically generated classes.

The primary constraints are that there is only one module-info.java
file, and the mapping to a class output directory.

There is nothing to prevent you recompiling an entire module, including
test code, to create a new version of the module, including the test
code. If you so choose.

-- Jon
cheers,
Rémi
Alan, Jon,
i think javac -Xmodule should merge the module-info.java from
the existing module and the one declared in the directory,
with the current semantics of the module-info, merging of
modules is easy and with no corner cases,
so for testing, the test will be able to declare their own
dependencies inside their own module-info.java.
Proposed semantics for merging,
- do the union of the required modules
- if one required module is required publicly, it will be
required publicly.
- do the union of the exported packages
- if one exported package is restricted, do the union of the restriction
- do the union of the uses.
- do the union of the provides.
so merging two modules is symmetric and will always succeed.
Rémi
----- Mail original -----
Envoyé: Mercredi 30 Mars 2016 15:45:03
Objet: Re: modulepath and classpath mixture
Post by Russell Gold
So if the tests and main code are both in directories,
which they have been
Post by Russell Gold
up to now in Maven, why would there be a problem? Both
would be in the
Post by Russell Gold
unnamed module and able to access one another.
There shouldn't any issue there, it should just work as it
has always done.
The thread here has meandered a bit but I think the scenario
under
discussion is tests for a module that need to nestmate with
the module
under test. The tests are in their own test tree. The tests
are compiled
separately from the module they test and may have additional
dependences
(such as on TestNG or JUnit for example). When compiling or
running then
the tests need to access public types in non-exported
packages and maybe
package private members too. The support for this has been
in jake for a
long time but involves command line options that many
developers or
build environments won't immediately grok. In particular the
tests have
to be compiled "as if" they augment the already compiled
module - that
is what javac -Xmodule is about. There is no need to
co-locate source
files or class files of course. When run then the -Xpatch
option is what
brings the tests and the module classes together. If we get
the tools
right then most developers won't ever see this of course.
One other thing to say that we've already been through some
of this with
the JDK tests. The jtreg test harness that we use for the
JDK tests has
been updated (thanks to Jon Gibbons) with useful support for
modules
[1]. It's enough for us to write tests that use JDK-internal
APIs or
write tests that nestmate with types in system modules so
that they get
access to package private type or public types in
non-exported packages.
It has rudimentary support for user modules too. Additional
dependences
are still an issue but our tests don't require additional
dependences
beyond TestNG. The test harness employs a bit of hackery to
get things
done, important when starting out, but I expect will go away
in time.
-Alan.
[1]
http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
--
Best Regards,
Ali Ebrahimi
Jonathan Gibbons
2016-03-31 01:29:55 UTC
Permalink
I have been following this thread, and it strongly reminds me of Joe
Darcy's parables of elephants and blind men. [1,2]

In this context, the discussion has been about testing, and the
underlying presumption that one size fits all.

I venture to suggest that one size does /not/ fit all, and that we have
to be able to support a wide range of testing paradigms.

1) Some folk will want to do black box testing, with their tests
contained in their own first class module, to exercise the code the way
that real clients might do

2) Some folk will want to do black box testing, with their test code on
the classpath, in the unnamed module, because they don't want to update
their test code

3) Some folk will want to do white box testing, using code conventions
is widespread use today, where the test code is alongside the code being
tested, in the same package. This generates two sub-cases: a) is the
test code compiled into the module itself, in a special test-specific
build, or b) is the test code dynamically patched into the module

4) Some folk will want to do white box testing, but will be less
concerned about the package used to contain the package. That has the
same two sub-cases: a) is the test code compiled into the module
itself, in a special test-specific build, or b) is the test code
dynamically patched into the module

Now you take all those scenarios, and cross-product them with issues
like, is there a test framework involved, such as JUnit or TestNG, and,
where should that framework be placed: can it be an automatic module, or
it is sufficient to put the framework on the classpath, in the unnamed
module?

When you understand all that, then you begin to see the shape of the
elephant in the room that is the testing problem.

But, to stretch the analogy to breaking point, it's not the only
elephant in the room. There's another, different, elephant called
"strong encapsulation", and there is a strong conflict between the
desire for easy white box testing and the desire for strong
encapsulation. While the past 20 years of Java have led to easy simple
white box testing, leveraging split packages by adding jars onto the
class path, we've also seen the the problems that such techniques can
lead to ... hence the desire for Project Jigsaw, and the requirement [3]
for strong encapsulation. We have to accept that the better we succeed
at strong encapsulation, the harder it will be to use the old ways of
white box testing. Conversely, the more we hold to the old ways of
working, the less we will succeed at satisfying the goal of strong
encapsulation.

So, ultimately, the trick is to figure out how to walk the tightrope
between the two elephants in the room. Previously, as a community,
we've built tools to help manage the task. Now, it is time for the tools
and our practices to evolve, to meet the new demands of testing in a
modular world.

Do we have all the answers today? Almost certainly not. But I will note
one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
always been important, and we have managed to keep running almost all of
the JDK unit and regression tests with little to no change in
functionality in almost all of the tests, and we have started supporting
new testing scenarios as well. Looking back at the list I gave at the
beginning, support for 1 is coming available, but not yet widely used,
many JDK tests use case 2, JDK has a number of tests that use 3b and
4b, and we have tests that use JUnit and TestNG.

So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may
not be pretty, but they can be composed to cover a wide range of testing
scenarios, without giving up too much on the goal of strong
encapsulation, and that at least is some degree of success.

-- Jon

[1]
https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language
[2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
[3] http://openjdk.java.net/projects/jigsaw/spec/reqs/
f***@univ-mlv.fr
2016-04-01 21:55:07 UTC
Permalink
Hi Jon,
thanks for taking the time to explain the whole picture, as you know, you are probably the one with most experience about testing in the modular world.

This threads starts with this question, how to do unit testing with Maven when everything is a module, your case 3, so i will focus on that case.
Here is my question, in case of 3a or 3b, i don't see how to explain to javac how to compile if there are some specific dependencies for the test (that are also modules).

regards,
Rémi

----- Mail original -----
Envoyé: Jeudi 31 Mars 2016 03:29:55
Objet: Re: modulepath and classpath mixture
I have been following this thread, and it strongly reminds me of Joe
Darcy's parables of elephants and blind men. [1,2]
In this context, the discussion has been about testing, and the
underlying presumption that one size fits all.
I venture to suggest that one size does /not/ fit all, and that we have
to be able to support a wide range of testing paradigms.
1) Some folk will want to do black box testing, with their tests
contained in their own first class module, to exercise the code the way
that real clients might do
2) Some folk will want to do black box testing, with their test code on
the classpath, in the unnamed module, because they don't want to update
their test code
3) Some folk will want to do white box testing, using code conventions
is widespread use today, where the test code is alongside the code being
tested, in the same package. This generates two sub-cases: a) is the
test code compiled into the module itself, in a special test-specific
build, or b) is the test code dynamically patched into the module
4) Some folk will want to do white box testing, but will be less
concerned about the package used to contain the package. That has the
same two sub-cases: a) is the test code compiled into the module
itself, in a special test-specific build, or b) is the test code
dynamically patched into the module
Now you take all those scenarios, and cross-product them with issues
like, is there a test framework involved, such as JUnit or TestNG, and,
where should that framework be placed: can it be an automatic module, or
it is sufficient to put the framework on the classpath, in the unnamed
module?
When you understand all that, then you begin to see the shape of the
elephant in the room that is the testing problem.
But, to stretch the analogy to breaking point, it's not the only
elephant in the room. There's another, different, elephant called
"strong encapsulation", and there is a strong conflict between the
desire for easy white box testing and the desire for strong
encapsulation. While the past 20 years of Java have led to easy simple
white box testing, leveraging split packages by adding jars onto the
class path, we've also seen the the problems that such techniques can
lead to ... hence the desire for Project Jigsaw, and the requirement [3]
for strong encapsulation. We have to accept that the better we succeed
at strong encapsulation, the harder it will be to use the old ways of
white box testing. Conversely, the more we hold to the old ways of
working, the less we will succeed at satisfying the goal of strong
encapsulation.
So, ultimately, the trick is to figure out how to walk the tightrope
between the two elephants in the room. Previously, as a community,
we've built tools to help manage the task. Now, it is time for the tools
and our practices to evolve, to meet the new demands of testing in a
modular world.
Do we have all the answers today? Almost certainly not. But I will note
one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
always been important, and we have managed to keep running almost all of
the JDK unit and regression tests with little to no change in
functionality in almost all of the tests, and we have started supporting
new testing scenarios as well. Looking back at the list I gave at the
beginning, support for 1 is coming available, but not yet widely used,
many JDK tests use case 2, JDK has a number of tests that use 3b and
4b, and we have tests that use JUnit and TestNG.
So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may
not be pretty, but they can be composed to cover a wide range of testing
scenarios, without giving up too much on the goal of strong
encapsulation, and that at least is some degree of success.
-- Jon
[1]
https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language
[2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
[3] http://openjdk.java.net/projects/jigsaw/spec/reqs/
Jonathan Gibbons
2016-04-01 22:51:10 UTC
Permalink
Rémi,

I think all of us working on Jigsaw have equally shared the experience of figuring out how to do testing in this modular world.

Currently, the solution to your problem is to use javac's -XaddReads option, which is to javac's compilation environment what the launcher's -XaddReads option is to the execution environment.

Just as the runtime provides a family of options to configure the modules is use at runtime,
-upgrademodulepath -modulepath -addmods -limitmods -XaddReads -XaddExports -Xpatch etc
so too does javac have an equivalent set of options to configure the modules in use at compile time.

The primary additions/differences at compile time:
-modulesourcepath (obviously source in not applicable at runtime)
-system (when compiling, you can override the default target system)
-Xmodule for compiling additional classes to patch into a module

-- Jon
Post by f***@univ-mlv.fr
Hi Jon,
thanks for taking the time to explain the whole picture, as you know, you are probably the one with most experience about testing in the modular world.
This threads starts with this question, how to do unit testing with Maven when everything is a module, your case 3, so i will focus on that case.
Here is my question, in case of 3a or 3b, i don't see how to explain to javac how to compile if there are some specific dependencies for the test (that are also modules).
regards,
Rémi
----- Mail original -----
Envoyé: Jeudi 31 Mars 2016 03:29:55
Objet: Re: modulepath and classpath mixture
I have been following this thread, and it strongly reminds me of Joe
Darcy's parables of elephants and blind men. [1,2]
In this context, the discussion has been about testing, and the
underlying presumption that one size fits all.
I venture to suggest that one size does /not/ fit all, and that we have
to be able to support a wide range of testing paradigms.
1) Some folk will want to do black box testing, with their tests
contained in their own first class module, to exercise the code the way
that real clients might do
2) Some folk will want to do black box testing, with their test code on
the classpath, in the unnamed module, because they don't want to update
their test code
3) Some folk will want to do white box testing, using code conventions
is widespread use today, where the test code is alongside the code being
tested, in the same package. This generates two sub-cases: a) is the
test code compiled into the module itself, in a special test-specific
build, or b) is the test code dynamically patched into the module
4) Some folk will want to do white box testing, but will be less
concerned about the package used to contain the package. That has the
same two sub-cases: a) is the test code compiled into the module
itself, in a special test-specific build, or b) is the test code
dynamically patched into the module
Now you take all those scenarios, and cross-product them with issues
like, is there a test framework involved, such as JUnit or TestNG, and,
where should that framework be placed: can it be an automatic module, or
it is sufficient to put the framework on the classpath, in the unnamed
module?
When you understand all that, then you begin to see the shape of the
elephant in the room that is the testing problem.
But, to stretch the analogy to breaking point, it's not the only
elephant in the room. There's another, different, elephant called
"strong encapsulation", and there is a strong conflict between the
desire for easy white box testing and the desire for strong
encapsulation. While the past 20 years of Java have led to easy simple
white box testing, leveraging split packages by adding jars onto the
class path, we've also seen the the problems that such techniques can
lead to ... hence the desire for Project Jigsaw, and the requirement [3]
for strong encapsulation. We have to accept that the better we succeed
at strong encapsulation, the harder it will be to use the old ways of
white box testing. Conversely, the more we hold to the old ways of
working, the less we will succeed at satisfying the goal of strong
encapsulation.
So, ultimately, the trick is to figure out how to walk the tightrope
between the two elephants in the room. Previously, as a community,
we've built tools to help manage the task. Now, it is time for the tools
and our practices to evolve, to meet the new demands of testing in a
modular world.
Do we have all the answers today? Almost certainly not. But I will note
one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
always been important, and we have managed to keep running almost all of
the JDK unit and regression tests with little to no change in
functionality in almost all of the tests, and we have started supporting
new testing scenarios as well. Looking back at the list I gave at the
beginning, support for 1 is coming available, but not yet widely used,
many JDK tests use case 2, JDK has a number of tests that use 3b and
4b, and we have tests that use JUnit and TestNG.
So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may
not be pretty, but they can be composed to cover a wide range of testing
scenarios, without giving up too much on the goal of strong
encapsulation, and that at least is some degree of success.
-- Jon
[1]
https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language
[2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
[3] http://openjdk.java.net/projects/jigsaw/spec/reqs/
Paul Benedict
2016-03-30 14:47:04 UTC
Permalink
Russell, if you have a module with package X and a classpath jar with
package X, the module can't see package X from the classpath.

In the last several posts, there's been discussion on putting tests on the
classpath; keeping the "main" code in the module. So given what I stated
above, that's what I've been referring to.

Cheers,
Paul
Post by Russell Gold
Hi Paul,
Could you explain? What kind of code do you mean cannot access it? And
what do you mean by “a split package situation”?
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part
of the unnamed module
Yes
So if the tests and main code are both in directories, which they have
been up to now in Maven, why would there be a problem? Both would be in the
unnamed module and able to access one another.
- Russ
Russell, when you drop a jar on the classpath, module code will not be
able to access it in a split package situation. That's the big barrier
here. Maven test projects are typically written with the same package
shared with the "main" code.
Cheers,
Paul
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be.
The tests can simply run with the production code on the class path, and
then there are no module issues at all.
I think a larger problem is that you can do what I just said with the
jars, even a jar which has been designated as a module by virtue of having
a module-info.class in it. That means that, when users are up taking jars,
they are not prevented from accessing module internals. They can put the
jars on the module path, of course, but they can still use them on the
class path!
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as different modules can be attractive because everything seems to be put
at the right place but there is a big drawback. Because modules are reified
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
Post by Stephen Colebourne
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
Post by Stephen Colebourne
Post by Remi Forax
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as one
module,
Post by Stephen Colebourne
Post by Remi Forax
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Post by Stephen Colebourne
Post by Remi Forax
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where
B
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks
Post by Stephen Colebourne
Post by Remi Forax
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Stephen Colebourne
Post by Remi Forax
are instead compiled and run in a way that patches the main module.
The
Post by Stephen Colebourne
Post by Remi Forax
second difference is that they don't have their own module
declaration,
Post by Stephen Colebourne
Post by Remi Forax
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Russell Gold
2016-03-30 19:07:22 UTC
Permalink
Hi Paul,

Why would you put your main code on the module path during a unit test? It seems to me that unit tests are explicitly about making sure that the code works, not the packaging. So you put both main and test code on the classpath, and there is no problem. The unit test can be done before the main code is packaged into a module.

- Russ
Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath.
In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to.
Cheers,
Paul
Hi Paul,
Could you explain? What kind of code do you mean cannot access it? And what do you mean by “a split package situation”?
Post by Russell Gold
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part of the unnamed module
Yes
So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another.
- Russ
Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code.
Cheers,
Paul
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all.
I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path!
- Russ
Post by Russell Gold
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Paul Benedict
2016-03-30 19:13:10 UTC
Permalink
Russell, you ask a good question. If an artifact is meant to be a module,
wouldn't it make sense for it to run as a module during testing too? Those
boundaries should be activated like they are in production to get good
confidence in the code. Those are my two cents. I'd like to hear opposing
opinions though why the boundaries shouldn't be there.

Cheers,
Paul
Post by Russell Gold
Hi Paul,
Why would you put your main code on the module path *during a unit test*?
It seems to me that unit tests are explicitly about making sure that the
code works, not the packaging. So you put both main and test code on the
classpath, and there is no problem. The unit test can be done before the
main code is packaged into a module.
- Russ
Russell, if you have a module with package X and a classpath jar with
package X, the module can't see package X from the classpath.
In the last several posts, there's been discussion on putting tests on the
classpath; keeping the "main" code in the module. So given what I stated
above, that's what I've been referring to.
Cheers,
Paul
Post by Russell Gold
Hi Paul,
Could you explain? What kind of code do you mean cannot access it? And
what do you mean by “a split package situation”?
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part
of the unnamed module
Yes
So if the tests and main code are both in directories, which they have
been up to now in Maven, why would there be a problem? Both would be in the
unnamed module and able to access one another.
- Russ
Russell, when you drop a jar on the classpath, module code will not be
able to access it in a split package situation. That's the big barrier
here. Maven test projects are typically written with the same package
shared with the "main" code.
Cheers,
Paul
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be.
The tests can simply run with the production code on the class path, and
then there are no module issues at all.
I think a larger problem is that you can do what I just said with the
jars, even a jar which has been designated as a module by virtue of having
a module-info.class in it. That means that, when users are up taking jars,
they are not prevented from accessing module internals. They can put the
jars on the module path, of course, but they can still use them on the
class path!
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the
test as different modules can be attractive because everything seems to be
put at the right place but there is a big drawback. Because modules are
reified at runtime, it means that the runtime environment of the tests will
be different from the production environment.
Post by Stephen Colebourne
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
Post by Stephen Colebourne
Post by Remi Forax
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as one
module,
Post by Stephen Colebourne
Post by Remi Forax
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Post by Stephen Colebourne
Post by Remi Forax
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test
where B
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
depends on A. Module A-test may have a method foo() that uses
package
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks
Post by Stephen Colebourne
Post by Remi Forax
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Stephen Colebourne
Post by Remi Forax
are instead compiled and run in a way that patches the main module.
The
Post by Stephen Colebourne
Post by Remi Forax
second difference is that they don't have their own module
declaration,
Post by Stephen Colebourne
Post by Remi Forax
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Ali Ebrahimi
2016-03-30 19:24:13 UTC
Permalink
Just add these to Paul's response, what about multi-module apps? Do we
coming back to non-modular world?
Post by Paul Benedict
Russell, you ask a good question. If an artifact is meant to be a module,
wouldn't it make sense for it to run as a module during testing too? Those
boundaries should be activated like they are in production to get good
confidence in the code. Those are my two cents. I'd like to hear opposing
opinions though why the boundaries shouldn't be there.
Cheers,
Paul
Post by Russell Gold
Hi Paul,
Why would you put your main code on the module path *during a unit test*?
It seems to me that unit tests are explicitly about making sure that the
code works, not the packaging. So you put both main and test code on the
classpath, and there is no problem. The unit test can be done before the
main code is packaged into a module.
- Russ
Russell, if you have a module with package X and a classpath jar with
package X, the module can't see package X from the classpath.
In the last several posts, there's been discussion on putting tests on
the
Post by Russell Gold
classpath; keeping the "main" code in the module. So given what I stated
above, that's what I've been referring to.
Cheers,
Paul
Post by Russell Gold
Hi Paul,
Could you explain? What kind of code do you mean cannot access it? And
what do you mean by “a split package situation”?
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part
of the unnamed module
Yes
So if the tests and main code are both in directories, which they have
been up to now in Maven, why would there be a problem? Both would be in
the
Post by Russell Gold
Post by Russell Gold
unnamed module and able to access one another.
- Russ
Russell, when you drop a jar on the classpath, module code will not be
able to access it in a split package situation. That's the big barrier
here. Maven test projects are typically written with the same package
shared with the "main" code.
Cheers,
Paul
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be.
The tests can simply run with the production code on the class path,
and
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
then there are no module issues at all.
I think a larger problem is that you can do what I just said with the
jars, even a jar which has been designated as a module by virtue of
having
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
a module-info.class in it. That means that, when users are up taking
jars,
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
they are not prevented from accessing module internals. They can put
the
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
jars on the module path, of course, but they can still use them on the
class path!
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the
test as different modules can be attractive because everything seems
to be
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
put at the right place but there is a big drawback. Because modules are
reified at runtime, it means that the runtime environment of the tests
will
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
be different from the production environment.
Post by Stephen Colebourne
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other
cases
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model,
putting
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so
any
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
Post by Stephen Colebourne
Post by Remi Forax
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them
as one
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
module,
Post by Stephen Colebourne
Post by Remi Forax
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Post by Stephen Colebourne
Post by Remi Forax
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at
the
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
main module
- the test module needs to be able to invoke package-scoped code
in
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test
where B
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
depends on A. Module A-test may have a method foo() that uses
package
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
scope to access something in A. Module B-test will depend on
A-test
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks
Post by Stephen Colebourne
Post by Remi Forax
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Stephen Colebourne
Post by Remi Forax
are instead compiled and run in a way that patches the main module.
The
Post by Stephen Colebourne
Post by Remi Forax
second difference is that they don't have their own module
declaration,
Post by Stephen Colebourne
Post by Remi Forax
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they
tools
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is
no
Post by Russell Gold
Post by Russell Gold
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
support for that.
-Alan
--
Best Regards,
Ali Ebrahimi
Russell Gold
2016-03-31 14:00:10 UTC
Permalink
Hi Paul,

No, it does not make sense, if you are writing unit tests. Unit tests often access classes and methods that general uses of the module should not. On the other hand, it could make perfect sense to run the code as a module in a functional test. Functional/integration/acceptance tests should only access what users of the module can access, and don’t need to be in the same packages as the code, since the users of that code aren’t.

Regards,
Russ
Russell, you ask a good question. If an artifact is meant to be a module, wouldn't it make sense for it to run as a module during testing too? Those boundaries should be activated like they are in production to get good confidence in the code. Those are my two cents. I'd like to hear opposing opinions though why the boundaries shouldn't be there.
Cheers,
Paul
Hi Paul,
Why would you put your main code on the module path during a unit test? It seems to me that unit tests are explicitly about making sure that the code works, not the packaging. So you put both main and test code on the classpath, and there is no problem. The unit test can be done before the main code is packaged into a module.
- Russ
Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath.
In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to.
Cheers,
Paul
Hi Paul,
Could you explain? What kind of code do you mean cannot access it? And what do you mean by “a split package situation”?
Post by Russell Gold
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part of the unnamed module
Yes
So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another.
- Russ
Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code.
Cheers,
Paul
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all.
I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path!
- Russ
Post by Russell Gold
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Stephen Colebourne
2016-03-30 09:26:44 UTC
Permalink
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all.
The underlying message of Jigsaw is that the classpath is going away.
An approach that requires use of the classpath is therefore not really
a solution to the real problem.

Stephen
Post by Remi Forax
I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path!
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment.
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module.
So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module,
maybe javac should help by providing a way to merge 2 module-info at compile time.
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
Ali Ebrahimi
2016-03-30 09:59:09 UTC
Permalink
Also, we should look for solutions not workaround( or hacks) in remaining
time. I think classpath was that problem we trying avoid (or solve) with
jigsaw.
Post by Russell Gold
Post by Remi Forax
Hi Stephen,
Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be.
The tests can simply run with the production code on the class path, and
then there are no module issues at all.
The underlying message of Jigsaw is that the classpath is going away.
An approach that requires use of the classpath is therefore not really
a solution to the real problem.
Stephen
Post by Remi Forax
I think a larger problem is that you can do what I just said with the
jars, even a jar which has been designated as a module by virtue of having
a module-info.class in it. That means that, when users are up taking jars,
they are not prevented from accessing module internals. They can put the
jars on the module path, of course, but they can still use them on the
class path!
Post by Remi Forax
- Russ
Post by Stephen Colebourne
Post by Remi Forax
Hi Stephen, Hi all,
I think that delivering tests as a separated module is a bad idea.
I see that from the point of a developer, seeing the code and the test
as different modules can be attractive because everything seems to be put
at the right place but there is a big drawback. Because modules are reified
at runtime, it means that the runtime environment of the tests will be
different from the production environment.
Post by Remi Forax
Post by Stephen Colebourne
This last sentence doesn't make sense to me - tests are not run in a
production environment.
Tests have all the qualities of modules - code, dependencies,
compilation phase, deployment. The only special part is the need for
special "friend-like" access, which Jigsaw already has for other cases
(the export...to clause).
Put simply, I consider that module =
deployment-artifact-with-dependencies. With that mental model, putting
tests inside the module is just not acceptable, because tests should
not be deployed with the main application and they have different
dependencies. If we disagree that module =
deployment-artifact-with-dependencies, then perhaps we have bigger
problems to solve here.
Stephen
(And to Paul Benedict, the classpath is going to die over time, so any
solution that uses that is flawed IMO).
Post by Remi Forax
So as Alan said, from the jigsaw point of view at runtime, the tests
and the code should be in the same module.
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
So the building tools have to come with a way to support to have 2
different module-info.java in two different folders and package them as one
module,
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
maybe javac should help by providing a way to merge 2 module-info at
compile time.
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Rémi
----- Mail original -----
Envoyé: Mercredi 23 Mars 2016 16:18:50
Objet: Re: modulepath and classpath mixture
Post by Stephen Colebourne
I don't particularly care what the mechanism is for this, but at the
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as
the
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where
B
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
Post by Stephen Colebourne
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing
frameworks
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module,
they
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
are instead compiled and run in a way that patches the main module.
The
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
second difference is that they don't have their own module
declaration,
Post by Remi Forax
Post by Stephen Colebourne
Post by Remi Forax
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
Post by Stephen Colebourne
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
--
Best Regards,
Ali Ebrahimi
Alan Bateman
2016-03-30 10:23:29 UTC
Permalink
Post by Stephen Colebourne
The underlying message of Jigsaw is that the classpath is going away.
There are no plans, at least not in this project, to remove the class
path. There is of course a better world beyond the class path, it's just
going to take a long time and require a lot of existing code and
configuration to be cleaned up in order to get there. We have a good
story for modules and the class path to co-exist and we expect they will
co-exist for a long long time, maybe forever.

-Alan.
Russell Gold
2016-03-23 13:02:10 UTC
Permalink
Post by Russell Gold
I’d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should.
1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well.
2) the artifact type “module” (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path)
3) the classes being built may be put into their own module, but might not be.
Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing.
The test-compile step needs to handle all four, including the compiled class in its test class path.
Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies.
Did I completely miss the point?
It depends on where the tests live. If they are black box tests that only exercise the API (the public types in the module's exported packages) then they can live anywhere. If they are in the same class loader and package as the code they are testing (the norm in Maven) then they need to compiled as if they are part of the module. We might think of these as white box tests as they can make use of public types in packages that aren't exported, maybe they are using package-private types/methods too.
Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no?

- Russ
Alan Bateman
2016-03-23 14:05:19 UTC
Permalink
Post by Russell Gold
Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no?
I'm not sure that I understand your mail. Are you asking why are modules
are supported at compile-time? Or are you asking why the compiler
doesn't allow packages to be split between the unnamed module and a
named module?

-Alan.
Russell Gold
2016-03-23 14:15:04 UTC
Permalink
Here are my assumptions, which you can correct.

1. A jar or classes directory placed on a class path are treated as part of the unnamed module
2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages
3. A jmod file is only usable on the module path.

If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn’t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn’t provide access to third parties, as code would not be distributed as loose classes.

- Russ
Post by Russell Gold
Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no?
I'm not sure that I understand your mail. Are you asking why are modules are supported at compile-time? Or are you asking why the compiler doesn't allow packages to be split between the unnamed module and a named module?
-Alan.
Alan Bateman
2016-03-23 15:42:23 UTC
Permalink
Post by Russell Gold
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part of the unnamed module
Yes
Post by Russell Gold
2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages
It also declares what it depends on and maybe services that it
uses/provides.

Also a JAR file on the module path without a module-info.class is
treated as an automatic module.
Post by Russell Gold
3. A jmod file is only usable on the module path.
JMOD files are unlikely to be seen by most developers. They are not an
executable format. They are mostly for link-time when creating a custom
run-time image.
Post by Russell Gold
If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn’t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn’t provide access to third parties, as code would not be distributed as loose classes.
You would loose the benefits of the module path and I assume couldn't
distinguish automatic modules from regular JAR files. In general I would
think this would be just confusing and I don't know what problem it
would solve.

-Alan
Russell Gold
2016-03-24 03:37:11 UTC
Permalink
Post by Russell Gold
Here are my assumptions, which you can correct.
1. A jar or classes directory placed on a class path are treated as part of the unnamed module
Yes
Then it seems to me that there isn’t actually a problem, here. Build tools can continue to work unchanged, using class paths to allow unit tests to access the code they are testing. The jars are then treated as modules by other builds, which shouldn’t be accessing the module internals in any case. If they really do need to access them, they just put those jars on their class paths - but that’s a hint of poor modularity and testability.
Post by Russell Gold
2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages
It also declares what it depends on and maybe services that it uses/provides.
Also a JAR file on the module path without a module-info.class is treated as an automatic module.
And what is an automatic module? I didn’t see that in the specs
Post by Russell Gold
3. A jmod file is only usable on the module path.
JMOD files are unlikely to be seen by most developers. They are not an executable format. They are mostly for link-time when creating a custom run-time image.
Post by Russell Gold
If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn’t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn’t provide access to third parties, as code would not be distributed as loose classes.
You would loose the benefits of the module path and I assume couldn't distinguish automatic modules from regular JAR files. In general I would think this would be just confusing and I don't know what problem it would solve.
It doesn’t, because it was based on my assumptions being wrong :)

I was trying to understand the problems Robert and Stephen were raising - and I cannot see the issue.

- Russ
Paul Benedict
2016-03-09 17:22:24 UTC
Permalink
I have an idea:

What if the jar tool in JDK 9 was upgraded so that the Manifest had a new
entry that contained the module name? This would allow access to it without
requiring new API, and tools running JDK 8 or below would have an easy way
to detect if the JAR is a module.

And is there a secondary benefit to decoupling the module name and the
module configuration? I'd like to hear another use case, if one exists.
* Robert, it's sounds like a chicken-and-egg problem. You need the module
*>* name to compile but don't know it until you have compiled.
*>I think the scenario is where the module has been compiled and the issue
is the separate compilation of the tests "as if" they are in the module.
-Alan
Cheers,
Paul
Loading...