module naming syntax

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

module naming syntax

Glenn Burkhardt
I'm puzzled about which utility should be more flexible about the module
naming convention.  With Java 11 from OpenJDK, I notice that

     java --module-path=jaxb-ri/mod -m
com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade -d out -p generated
Schema_Specification.xsd

works as desired, but

     java --module-path=jaxb-ri/mod -m
com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade -d out -p
generated.armisxml Schema_Specification.xsd

does not (only difference is the use of '\' and '/' in the module name).

When one tries to use a Java task in 'ant', it translates the forward
slash to a backward slash, e.g.,

   <java fork="true" modulepath="axb-ri/mod"
module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
                 <arg value="-d out"/>
                 <arg value="-p generated"/>
                 <arg value="Schema_Specification.xsd"/>
  </java>

Running 'ant' in verbose mode, it shows that the argument "-m
com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
program.

So, which program should be more flexible?  I haven't found a
specification of what the module name specification should be. But the
OpenJDK Java program requires that a forward slash be used.  Should
'ant' not translate the forward slash into a backslash?  Or should the
OpenJDK Java program accept either one?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Jaikiran Pai-2
Hello Glenn,

I don't expect the module name's front slash to be replaced with a file
separator. I haven't checked the code yet. I'll take a look later today.
What operating system are you on and which exact version of Ant are you
using?

-Jaikiran

On 14/05/19 6:07 AM, Glenn Burkhardt wrote:

> I'm puzzled about which utility should be more flexible about the
> module naming convention.  With Java 11 from OpenJDK, I notice that
>
>     java --module-path=jaxb-ri/mod -m
> com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade -d out -p generated
> Schema_Specification.xsd
>
> works as desired, but
>
>     java --module-path=jaxb-ri/mod -m
> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade -d out -p
> generated.armisxml Schema_Specification.xsd
>
> does not (only difference is the use of '\' and '/' in the module name).
>
> When one tries to use a Java task in 'ant', it translates the forward
> slash to a backward slash, e.g.,
>
>   <java fork="true" modulepath="axb-ri/mod"
> module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>                 <arg value="-d out"/>
>                 <arg value="-p generated"/>
>                 <arg value="Schema_Specification.xsd"/>
>  </java>
>
> Running 'ant' in verbose mode, it shows that the argument "-m
> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
> program.
>
> So, which program should be more flexible?  I haven't found a
> specification of what the module name specification should be. But the
> OpenJDK Java program requires that a forward slash be used.  Should
> 'ant' not translate the forward slash into a backslash?  Or should the
> OpenJDK Java program accept either one?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Stefan Bodewig
On 2019-05-14, Jaikiran Pai wrote:

> I don't expect the module name's front slash to be replaced with a file
> separator.

Ant does, I'm pretty sure.

The type of <java>'s modulepath is an Ant Path and as such each entry is
treated as a file name and the usual file separator suspects are mapped
to their OS specific versions.

The argument is a path as it points to modules and uses the OS specific
module separator. I'm not sure how we best fix this, we could check each
entry to see whether it points to an existing archive or directory and
only adjust slashes if they are, maybe.

In either case this is something that needs to be fixed on the Ant side
of things.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Jaikiran Pai-2

On 14/05/19 11:48 AM, Stefan Bodewig wrote:
> On 2019-05-14, Jaikiran Pai wrote:
>
>> I don't expect the module name's front slash to be replaced with a file
>> separator.
> Ant does, I'm pretty sure.
>
> The type of <java>'s modulepath is an Ant Path and as such each entry is
> treated as a file name and the usual file separator suspects are mapped
> to their OS specific versions.

From what I understood of Glenn's mail, I thought he was talking about
the "module" attribute which is a name, unlike the modulepath, which as
you rightly note is a "path". As far as I understand of the java command
line, the -m option which specifies the module[/mainclassname] should be
taken literally without any file separator conversions. So before we
(Ant) pass off that module name to java command, IMO, we shouldn't do
the conversion.


-Jaikiran



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Stefan Bodewig
On 2019-05-14, Jaikiran Pai wrote:

> On 14/05/19 11:48 AM, Stefan Bodewig wrote:
>> On 2019-05-14, Jaikiran Pai wrote:

>>> I don't expect the module name's front slash to be replaced with a file
>>> separator.
>> Ant does, I'm pretty sure.

>> The type of <java>'s modulepath is an Ant Path and as such each entry is
>> treated as a file name and the usual file separator suspects are mapped
>> to their OS specific versions.

> From what I understood of Glenn's mail, I thought he was talking about
> the "module" attribute which is a name, unlike the modulepath, which as
> you rightly note is a "path".

No, from Glen's original mail

,----
| java --module-path=jaxb-ri/mod -m
`----

> As far as I understand of the java command line, the -m option which
> specifies the module[/mainclassname] should be taken literally without
> any file separator conversions.

Somewhat agreed, the logic in ClasspathJava#setModule contains some
special cases, but yes.

I believe in Glen's case this really is about module-path, though.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Stefan Bodewig
On 2019-05-14, Stefan Bodewig wrote:

> On 2019-05-14, Jaikiran Pai wrote:

>> On 14/05/19 11:48 AM, Stefan Bodewig wrote:
>>> On 2019-05-14, Jaikiran Pai wrote:

>>>> I don't expect the module name's front slash to be replaced with a file
>>>> separator.
>>> Ant does, I'm pretty sure.

>>> The type of <java>'s modulepath is an Ant Path and as such each entry is
>>> treated as a file name and the usual file separator suspects are mapped
>>> to their OS specific versions.

>> From what I understood of Glenn's mail, I thought he was talking about
>> the "module" attribute which is a name, unlike the modulepath, which as
>> you rightly note is a "path".

> No, from Glen's original mail

My fault, it is about the -m switch, sorry.

>> As far as I understand of the java command line, the -m option which
>> specifies the module[/mainclassname] should be taken literally without
>> any file separator conversions.

> Somewhat agreed, the logic in ClasspathJava#setModule contains some
> special cases, but yes.

It is more complex. COmmandlineJava's setModule ends up calling
Commandline's setExecutable which will translate file separators. This
is what we see in action here and what is a bug.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Stefan Bodewig
In reply to this post by Glenn Burkhardt
On 2019-05-14, Glenn Burkhardt wrote:

>   <java fork="true" modulepath="axb-ri/mod"
> module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>                 <arg value="-d out"/>
>                 <arg value="-p generated"/>
>                 <arg value="Schema_Specification.xsd"/>
>  </java>

> Running 'ant' in verbose mode, it shows that the argument "-m
> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
> program.

I think what happens here is CommandlineJava#setModule is called with
executableType being null and thus Commandline#setExecutable is called
without the second argument which would prevent slash translation.

From the top of my head I don't recall why we have a case for
executableType being null here at all rather than switching to module
mode immediately and processing the argument after that. There must be a
reason for that but figuring things out requires a bit more thought.

On second thought from looking at the code the java task seems to expect
you'd use

<java module="com.sun.tools.xjc"
      classname="com.sun.tools.xjc.XJCFacade" ...

instead. This contradicts the manual page which says module and
classname would couldn't be used at the same time, but please give it a
try.

The module attribute seems to really correspond to the module itself and
not the -m switch. We build the later from a combination of module and
classname.

At the very least we need to fix the documentation.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Glenn Burkhardt
In reply to this post by Jaikiran Pai-2
Windows 10, Ant 1.10.6

On 5/14/2019 1:27 AM, Jaikiran Pai wrote:

> Hello Glenn,
>
> I don't expect the module name's front slash to be replaced with a file
> separator. I haven't checked the code yet. I'll take a look later today.
> What operating system are you on and which exact version of Ant are you
> using?
>
> -Jaikiran
>
> On 14/05/19 6:07 AM, Glenn Burkhardt wrote:
>> I'm puzzled about which utility should be more flexible about the
>> module naming convention.  With Java 11 from OpenJDK, I notice that
>>
>>      java --module-path=jaxb-ri/mod -m
>> com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade -d out -p generated
>> Schema_Specification.xsd
>>
>> works as desired, but
>>
>>      java --module-path=jaxb-ri/mod -m
>> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade -d out -p
>> generated.armisxml Schema_Specification.xsd
>>
>> does not (only difference is the use of '\' and '/' in the module name).
>>
>> When one tries to use a Java task in 'ant', it translates the forward
>> slash to a backward slash, e.g.,
>>
>>    <java fork="true" modulepath="axb-ri/mod"
>> module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>>                  <arg value="-d out"/>
>>                  <arg value="-p generated"/>
>>                  <arg value="Schema_Specification.xsd"/>
>>   </java>
>>
>> Running 'ant' in verbose mode, it shows that the argument "-m
>> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
>> program.
>>
>> So, which program should be more flexible?  I haven't found a
>> specification of what the module name specification should be. But the
>> OpenJDK Java program requires that a forward slash be used.  Should
>> 'ant' not translate the forward slash into a backslash?  Or should the
>> OpenJDK Java program accept either one?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Glenn Burkhardt
In reply to this post by Jaikiran Pai-2
The question is about the module attribute (which gets translated into a
"-m" argument for 'java'), not the modulepath.

      [java] Executing 'C:\Program
Files\AdoptOpenJDK\jdk-11.0.3.7-openj9\bin\java.exe' with arguments:
      [java] '--module-path'
      [java] 'C:\Users\glenn\Documents\utc\jaxb\jaxb-ri\mod'
      [java] '-m'
      [java] 'com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade'
      [java] '-d out'
      [java] '-p generated'
      [java] 'Schema_Specification.xsd'
      [java]
      [java] The ' characters around the executable and arguments are
      [java] not part of the command.
      [java] java.lang.module.FindException: Module
com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade not found

On 5/14/2019 2:25 AM, Jaikiran Pai wrote:

> On 14/05/19 11:48 AM, Stefan Bodewig wrote:
>> On 2019-05-14, Jaikiran Pai wrote:
>>
>>> I don't expect the module name's front slash to be replaced with a file
>>> separator.
>> Ant does, I'm pretty sure.
>>
>> The type of <java>'s modulepath is an Ant Path and as such each entry is
>> treated as a file name and the usual file separator suspects are mapped
>> to their OS specific versions.
>  From what I understood of Glenn's mail, I thought he was talking about
> the "module" attribute which is a name, unlike the modulepath, which as
> you rightly note is a "path". As far as I understand of the java command
> line, the -m option which specifies the module[/mainclassname] should be
> taken literally without any file separator conversions. So before we
> (Ant) pass off that module name to java command, IMO, we shouldn't do
> the conversion.
>
>
> -Jaikiran
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Glenn Burkhardt
In reply to this post by Stefan Bodewig
On 5/14/2019 3:01 AM, Stefan Bodewig wrote:

> On 2019-05-14, Glenn Burkhardt wrote:
>
>>    <java fork="true" modulepath="axb-ri/mod"
>> module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>>                  <arg value="-d out"/>
>>                  <arg value="-p generated"/>
>>                  <arg value="Schema_Specification.xsd"/>
>>   </java>
>> Running 'ant' in verbose mode, it shows that the argument "-m
>> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
>> program.
> I think what happens here is CommandlineJava#setModule is called with
> executableType being null and thus Commandline#setExecutable is called
> without the second argument which would prevent slash translation.
>
>  From the top of my head I don't recall why we have a case for
> executableType being null here at all rather than switching to module
> mode immediately and processing the argument after that. There must be a
> reason for that but figuring things out requires a bit more thought.
>
> On second thought from looking at the code the java task seems to expect
> you'd use
>
> <java module="com.sun.tools.xjc"
>        classname="com.sun.tools.xjc.XJCFacade" ...
>
> instead. This contradicts the manual page which says module and
> classname would couldn't be used at the same time, but please give it a
> try.
>
> The module attribute seems to really correspond to the module itself and
> not the -m switch. We build the later from a combination of module and
> classname.
>
> At the very least we need to fix the documentation.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
  <java fork="true" modulepath="jaxb-ri/mod"
        module="com.sun.tools.xjc"
        classname="com.sun.tools.xjc.XJCFacade" >
    <arg value="-d"/>
    <arg value="out"/>
    <arg value="-p"/>
    <arg value="generated"/>
    <arg value="Schema_Specification.xsd"/>
  </java>

works.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: module naming syntax

Jaikiran Pai-2
In reply to this post by Stefan Bodewig

On 14/05/19 12:31 PM, Stefan Bodewig wrote:

> On 2019-05-14, Glenn Burkhardt wrote:
>
>>   <java fork="true" modulepath="axb-ri/mod"
>> module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>>                 <arg value="-d out"/>
>>                 <arg value="-p generated"/>
>>                 <arg value="Schema_Specification.xsd"/>
>>  </java>
>> Running 'ant' in verbose mode, it shows that the argument "-m
>> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
>> program.
> I think what happens here is CommandlineJava#setModule is called with
> executableType being null and thus Commandline#setExecutable is called
> without the second argument which would prevent slash translation.
>
> From the top of my head I don't recall why we have a case for
> executableType being null here at all rather than switching to module
> mode immediately and processing the argument after that. There must be a
> reason for that but figuring things out requires a bit more thought.
>
Now that Glenn seems to have got past the issue by following the
workaround suggested, do you think we should fix this code, to handle
the case where the module name could have a slash character. I think the
fix could be as simple as:


diff --git a/src/main/org/apache/tools/ant/types/CommandlineJava.java
b/src/main/org/apache/tools/ant/types/CommandlineJava.java
index 876675332..9f9b444e7 100644
--- a/src/main/org/apache/tools/ant/types/CommandlineJava.java
+++ b/src/main/org/apache/tools/ant/types/CommandlineJava.java
@@ -397,7 +397,7 @@ public class CommandlineJava implements Cloneable {
      */
     public void setModule(final String module) {
         if (executableType == null) {
-            javaCommand.setExecutable(module);
+            javaCommand.setExecutable(module, false);
         } else {
             switch (executableType) {
                 case JAR:

(of course with test cases added for this specific case).

Just like you, I'm not fully sure why that executableType == null check
is there. Maybe that whole if/else block along with the switch is trying
to take into account the case of attribute order parsing (for example,
the "classname" attribute having been parsed before the "module"
attribute because that's how the user used it?) while reading the
"<java>" element?

-Jaikiran



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]