You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2016/01/14 21:14:12 UTC
Re: Specifying module paths
Hi,
on the maven-dev list I've received a couple of responses.
The following comments are worth mentioning:
Igor Fedorenko says: "This is a very good proposal. My only suggestion is
to extend javax.tools CompilationTask API to take modulepath map as
in-memory parameter. Not a big deal, but it'll be silly to write
properties file to disk for it to be immediately read by the code executed
in the same jvm."
I agree with Igor on the in-memory option: JDK-8144665 is first of all
initiated as a request to have a more effective way to handle modules *for
build-tools*.
Paul Benedict says: "It sounds like Maven will have to generate many
.properties file in a build.
1) Modules to compile main source
2) Modules to compile test source
3) Modules to execute tests
4) And what about forking?
I am concerned #4 is going to create issues unless the .properties file
name is unique enough. Perhaps it can be based on process id."
I haven't had a look at surefire (framework for executing tests) yet, so
we still need to analyze the impact for it. What Tibor Digana told me is
that it leans on the Classpath element of the MANIFEST file.
My remarks:
There are 2 things important to me:
a. reference must result in a single file
A Maven Artifact coordinate refers to exactly one file. In the local
repository the folder containing that artifact often contains other files
as well and you cannot predict which files were intended to be added to
the class/module path just by referring to that folder. A properties file
would at least result in a 1:1 mapping from dependency to file.
b. predictable order
With the classpath it was the order of the cp-entries specified, and
Maven calculated that order based the "distance" of that dependency in
relation to the Java project, especially important with transitive
dependencies. Based on what I read about JEP-261 and 'order' it is *not*
the "requires X" from the module-info which decides the order. Just like
the cp argument it is based on the mp argument. This is interesting,
because what's the order of files within a folder? It depends on the OS
[1].
bq. There is no guarantee that the name strings in the resulting array
will appear in any specific order; they are not, in particular, guaranteed
to appear in alphabetical order.
Reordering dependencies is a well known trick in case of class collisions.
Regarding the extra file, I'm still not sure about it. To me it adds
unnecessary complexity. We didn't ask for a replacement of the current
behavior, just to *add* support for jars as -mp argument. For those who
want to use the commandline, the can still refer to module folders. As for
Maven (I cannot speak for other tools), we use the CompilerAPI, so
commandline-length is not the issue.
thanks,
Robert Scholte
[1] https://docs.oracle.com/javase/7/docs/api/java/io/File.html#list()
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Specifying module paths
Posted by Robert Scholte <rf...@apache.org>.
Hi Paul,
no, I'm not talking about multiple versions of the same module, that
subject is clear to me.
Alan described quite precise my issue (it's the first described usecase,
although the others are interesting as well). So it seems that if two
different modules export the same package, there will be a compilation
error. No chance of class collisions within a moduled system. That's a
very tight safety belt! For me it is too early to jump to conclusions, but
this might have bigger impact than the module separation itself.
thanks,
Robert
Op Fri, 15 Jan 2016 20:33:32 +0100 schreef Paul Benedict
<pb...@apache.org>:
> Robert, in the SOTM document, it explicitly calls out that Module systems
> are not required to support multiple versions of a module. Correct me if
> wrong, but I think you're hinting at that?
>
> Cheers,
> Paul
>
> On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons <
>> jonathan.gibbons@oracle.com>:
>>
>>
>>
>>>
>>> On 01/14/2016 12:25 PM, ecki@zusammenkunft.net wrote:
>>>
>>>> Hello,
>>>>
>>>> If I understood it correctly the modules on the MP must be unique and
>>>> are not merged, thats why the order inside the directory does not
>>>> matter
>>>> for the named modules.
>>>>
>>>> Bernd
>>>>
>>>>
>>> Let me refine that for you ...
>>>
>>> The modules in each directory on the module path must be unique. A
>>> module with a specific name in a directory on the module path will
>>> shadow
>>> (hide) any other module with the same name in a later directory on the
>>> path.
>>>
>>> So, the order of directories on the module path matters (just like the
>>> order of entries on a class path matters), but the "order" of entries
>>> within any specific directory on the module path does not matter.
>>>
>>> -- Jon
>>>
>>>
>>>
>> Suppose there's a logging module and a fat module, which also contains
>> the
>> classes of the logging module, but older.
>> In my module-info I have
>> requires logging;
>> requires fat;
>>
>> These modules are in the same directory. Which class is loaded first and
>> why? If it is the order in the module-info, then I would also like to
>> see
>> an example of the strategy with "requires public".
>>
>> thanks,
>> Robert
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Specifying module paths
Posted by Paul Benedict <pb...@apache.org>.
Robert, in the SOTM document, it explicitly calls out that Module systems
are not required to support multiple versions of a module. Correct me if
wrong, but I think you're hinting at that?
Cheers,
Paul
On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte <rf...@apache.org>
wrote:
> Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons <
> jonathan.gibbons@oracle.com>:
>
>
>
>>
>> On 01/14/2016 12:25 PM, ecki@zusammenkunft.net wrote:
>>
>>> Hello,
>>>
>>> If I understood it correctly the modules on the MP must be unique and
>>> are not merged, thats why the order inside the directory does not matter
>>> for the named modules.
>>>
>>> Bernd
>>>
>>>
>> Let me refine that for you ...
>>
>> The modules in each directory on the module path must be unique. A
>> module with a specific name in a directory on the module path will shadow
>> (hide) any other module with the same name in a later directory on the path.
>>
>> So, the order of directories on the module path matters (just like the
>> order of entries on a class path matters), but the "order" of entries
>> within any specific directory on the module path does not matter.
>>
>> -- Jon
>>
>>
>>
> Suppose there's a logging module and a fat module, which also contains the
> classes of the logging module, but older.
> In my module-info I have
> requires logging;
> requires fat;
>
> These modules are in the same directory. Which class is loaded first and
> why? If it is the order in the module-info, then I would also like to see
> an example of the strategy with "requires public".
>
> thanks,
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Specifying module paths
Posted by Alan Bateman <Al...@oracle.com>.
On 15/01/2016 09:06, Robert Scholte wrote:
>
> Suppose there's a logging module and a fat module, which also contains
> the classes of the logging module, but older.
> In my module-info I have
> requires logging;
> requires fat;
>
> These modules are in the same directory. Which class is loaded first
> and why? If it is the order in the module-info, then I would also like
> to see an example of the strategy with "requires public".
The module names seems to be unique here so it doesn't matter if these
two (packaged) modules are in the same directory or different
directories that you specify to -modulepath in random order.
The issue of modules with different names but overlapping packages is a
different topic but a topic where there is much to say.
Let's suppose that both module logging and module fat export the same
package. Now suppose you have a module m1 that requires logging and
requires fat. In that case you will get a compilation error as m1 is
reading two modules exporting the same package to m1. If there is
subterfuge used to compile this then it will fail at startup/runtime for
the same reason.
Now suppose that the logging API is exported by module logging but not
exported by module fat. This may be the example you have in mind. I
assume the owner of fat has decided to create this uber JAR with an old
version of logging and without re-packaging it. We'll assume m1 requires
logging and m1 requires fat as before. In that case, then m1 should
compile as the logging.* types are only coming from one module.
At run-time then it will fail at startup when logging and fat on the
application module path. The error is that module logging and module fat
cannot be defined to the same class loader because they have types in
the same package. This is not an inherit issue in the module system,
it's just a implementation limitation with modules on the application
module path. A more sophisticated launcher would use the Layer API to
put define modules with overlapping packages to different class loaders.
It's somewhat tricky for the this to be done automatically when there is
both an application module path and an application class path. The
reason is that components on the class path require visibility of
modules on the application module path. Conversely, automatic modules on
the application module path need types on the class path to be visible.
This is something that will need to be sorted out.
I realize this may be more than you were looking for but the point is
that there isn't any ambiguity as to where the logging classes are
loaded from. A module is making use of types in package p then those
types can only come from one module. The use of `requires public doesn't
change this, instead it just increases the set of modules that are read.
-Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Specifying module paths
Posted by Tibor Digana <ti...@googlemail.com>.
Ask the Oracle :)
The classloader must validate the modulepath tree before loading the class
files. WDYT?
On Fri, Jan 15, 2016 at 10:06 AM, Robert Scholte <rf...@apache.org>
wrote:
> Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons <
> jonathan.gibbons@oracle.com>:
>
>
>>
>> On 01/14/2016 12:25 PM, ecki@zusammenkunft.net wrote:
>>
>>> Hello,
>>>
>>> If I understood it correctly the modules on the MP must be unique and
>>> are not merged, thats why the order inside the directory does not matter
>>> for the named modules.
>>>
>>> Bernd
>>>
>>>
>> Let me refine that for you ...
>>
>> The modules in each directory on the module path must be unique. A
>> module with a specific name in a directory on the module path will shadow
>> (hide) any other module with the same name in a later directory on the path.
>>
>> So, the order of directories on the module path matters (just like the
>> order of entries on a class path matters), but the "order" of entries
>> within any specific directory on the module path does not matter.
>>
>> -- Jon
>>
>>
>>
> Suppose there's a logging module and a fat module, which also contains the
> classes of the logging module, but older.
> In my module-info I have
> requires logging;
> requires fat;
>
> These modules are in the same directory. Which class is loaded first and
> why? If it is the order in the module-info, then I would also like to see
> an example of the strategy with "requires public".
>
> thanks,
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Cheers
Tibor
Re: Specifying module paths
Posted by Robert Scholte <rf...@apache.org>.
Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons
<jo...@oracle.com>:
>
>
> On 01/14/2016 12:25 PM, ecki@zusammenkunft.net wrote:
>> Hello,
>>
>> If I understood it correctly the modules on the MP must be unique and
>> are not merged, thats why the order inside the directory does not
>> matter for the named modules.
>>
>> Bernd
>>
>
> Let me refine that for you ...
>
> The modules in each directory on the module path must be unique. A
> module with a specific name in a directory on the module path will
> shadow (hide) any other module with the same name in a later directory
> on the path.
>
> So, the order of directories on the module path matters (just like the
> order of entries on a class path matters), but the "order" of entries
> within any specific directory on the module path does not matter.
>
> -- Jon
>
>
Suppose there's a logging module and a fat module, which also contains the
classes of the logging module, but older.
In my module-info I have
requires logging;
requires fat;
These modules are in the same directory. Which class is loaded first and
why? If it is the order in the module-info, then I would also like to see
an example of the strategy with "requires public".
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Specifying module paths
Posted by ec...@zusammenkunft.net.
Hello,
If I understood it correctly the modules on the MP must be unique and are not merged, thats why the order inside the directory does not matter for the named modules.
Bernd
--
http://bernd.eckenfels.net
-----Original Message-----
From: Robert Scholte <rf...@apache.org>
To: jigsaw-dev@openjdk.java.net
Cc: Maven Developers List <de...@maven.apache.org>
Sent: Do., 14 Jan. 2016 21:14
Subject: Re: Specifying module paths
Hi,
on the maven-dev list I've received a couple of responses.
The following comments are worth mentioning:
Igor Fedorenko says: "This is a very good proposal. My only suggestion is
to extend javax.tools CompilationTask API to take modulepath map as
in-memory parameter. Not a big deal, but it'll be silly to write
properties file to disk for it to be immediately read by the code executed
in the same jvm."
I agree with Igor on the in-memory option: JDK-8144665 is first of all
initiated as a request to have a more effective way to handle modules *for
build-tools*.
Paul Benedict says: "It sounds like Maven will have to generate many
.properties file in a build.
1) Modules to compile main source
2) Modules to compile test source
3) Modules to execute tests
4) And what about forking?
I am concerned #4 is going to create issues unless the .properties file
name is unique enough. Perhaps it can be based on process id."
I haven't had a look at surefire (framework for executing tests) yet, so
we still need to analyze the impact for it. What Tibor Digana told me is
that it leans on the Classpath element of the MANIFEST file.
My remarks:
There are 2 things important to me:
a. reference must result in a single file
A Maven Artifact coordinate refers to exactly one file. In the local
repository the folder containing that artifact often contains other files
as well and you cannot predict which files were intended to be added to
the class/module path just by referring to that folder. A properties file
would at least result in a 1:1 mapping from dependency to file.
b. predictable order
With the classpath it was the order of the cp-entries specified, and
Maven calculated that order based the "distance" of that dependency in
relation to the Java project, especially important with transitive
dependencies. Based on what I read about JEP-261 and 'order' it is *not*
the "requires X" from the module-info which decides the order. Just like
the cp argument it is based on the mp argument. This is interesting,
because what's the order of files within a folder? It depends on the OS
[1].
bq. There is no guarantee that the name strings in the resulting array
will appear in any specific order; they are not, in particular, guaranteed
to appear in alphabetical order.
Reordering dependencies is a well known trick in case of class collisions.
Regarding the extra file, I'm still not sure about it. To me it adds
unnecessary complexity. We didn't ask for a replacement of the current
behavior, just to *add* support for jars as -mp argument. For those who
want to use the commandline, the can still refer to module folders. As for
Maven (I cannot speak for other tools), we use the CompilerAPI, so
commandline-length is not the issue.
thanks,
Robert Scholte
[1] https://docs.oracle.com/javase/7/docs/api/java/io/File.html#list()
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org