You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2018/09/26 12:04:18 UTC
[Bug 62764] New: junit: pathelement with wildcard fails running on
java 11 - InvalidPathException: Illegal char <*>
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
Bug ID: 62764
Summary: junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Product: Ant
Version: 1.10.5
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: notifications@ant.apache.org
Reporter: space008@gmx.net
Target Milestone: ---
Created attachment 36165
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36165&action=edit
example ant project
See attachment "myAntProject.zip"
With Java 8 both ant targets "junit_good_classpath" and "junit_bad_classpath"
runs successful.
With Java 11 ant target "junit_bad_classpath" fails with
"java.nio.file.InvalidPathException: Illegal char <*> at index 51:
C:\myAntProject\lib\*"
C:\myAntProject>ant junit_good_classpath
Buildfile: C:\myAntProject\build.xml
junit_good_classpath:
BUILD SUCCESSFUL
Total time: 0 seconds
C:\myAntProject>ant junit_bad_classpath
Buildfile: C:\myAntProject\build.xml
junit_bad_classpath:
BUILD FAILED
C:\myAntProject\build.xml:26: java.nio.file.InvalidPathException: Illegal char
<*> at index 51: C:\myAntProject\lib\*
at
java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at
java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at java.base/java.io.File.toPath(File.java:2290)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1222)
at
java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:726)
at
java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:843)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:246)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:176)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:346)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:317)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:283)
at
org.apache.tools.ant.AntClassLoader.addPathFile(AntClassLoader.java:501)
at
org.apache.tools.ant.AntClassLoader.addPathElement(AntClassLoader.java:459)
at
org.apache.tools.ant.AntClassLoader.setClassPath(AntClassLoader.java:368)
at org.apache.tools.ant.AntClassLoader.<init>(AntClassLoader.java:279)
at org.apache.tools.ant.AntClassLoader.<init>(AntClassLoader.java:300)
at
org.apache.tools.ant.util.SplitClassLoader.<init>(SplitClassLoader.java:42)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.lambda$setupJUnitDelegate$0(JUnitTask.java:821)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.setupJUnitDelegate(JUnitTask.java:819)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:845)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
at org.apache.tools.ant.Project.executeTarget(Project.java:1361)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:834)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
Total time: 0 seconds
C:\myAntProject>ant -version
Apache Ant(TM) version 1.10.5 compiled on July 10 2018
C:\myAntProject>java -version
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #5 from Jaikiran Pai <ja...@apache.org> ---
>> With <junit fork="true"> is the same problem.
Can you attach the output of:
ant -v junit_bad_classpath
with fork=true for that task?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #11 from Jaikiran Pai <ja...@apache.org> ---
The Java issue that we raised with the OpenJDK team has now been fixed in Java
12 early access build 15 as noted in [1]. You can download that version and
give it a try if you want to verify it. I haven't had a chance to try it out
myself, but I do expect that fix to work.
[1] https://www.mail-archive.com/dev@ant.apache.org/msg47635.html
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
Jaikiran Pai <ja...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Jaikiran Pai <ja...@apache.org> ---
>> There's a discussion going on in the OpenJDK dev list on whether the code needs to be fixed to wrap and throw an IOException or whether the javadoc/API expectations of these constructors need to be updated to mention that the java.nio.file.InvalidPathException can be thrown from them. Depending on what decision is arrived at, we may or may not need a change in Ant project. I'll keep this issue open until then.
It has been confirmed that this is going to be just an internal implementation
fix in the Java implementation. As a result, there isn't anything more Ant
project needs to do to handle this.
Marking this as resolved "Invalid" because this isn't a bug in Ant. However,
thank you very much for reporting and providing enough details about this
issue, for us to be able to narrow this down to a Java bug.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #2 from space008@gmx.net ---
My OS is "Windows 7 64bit". The Ant script works fine with Java 8, but if fails
with Java 11.
I'm using the feature of "pathelement"-tag to use a wildcard at the end of the
attribute "location".
It's described in https://ant.apache.org/manual/using.html#path
I need the wildcard in the classpath in the ant build of my projects.
Without a wildcard the classpath string is too long and the junit task crashes.
With a wildcard the classpath is shorter the junit task works fine.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #3 from Stefan Bodewig <bo...@apache.org> ---
It is supposed to work, see
https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
and it works using 11-ea+19 on Linux, BUT
1- the build file doesn't fork the JVM in this case I'm not really sure who is
supposed to expand the *
2. I can savely remove the pathelement with the * and the test still passes, so
I can't be sure it has any effect at all
space008@gmx.net do things change if you throw in a fork="true" ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
Jaikiran Pai <ja...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Jaikiran Pai <ja...@apache.org> ---
On my local *nix setup, I can't get this to work properly on Java 8 either. I
don't run into the exception you are seeing, but the use of "lib/*" like you do
in the build.xml doesn't really include the jar files in the lib directory and
as a result, the build fails with ClassNotFoundException(s). Enabling verbose
logging shows this:
"adding /home/me/test/lib/* which contains wildcards and may not do what you
intend it to do depending on your OS or version of Java"
So it does appear that this usage isn't really expected to work credibly.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #7 from Jaikiran Pai <ja...@apache.org> ---
Hello space008@gmx.net,
With fork=true, things work fine for me on my *nix setup both with Java 8 and
Java 11. For the sake of being clear, here's the target I have, that works
fine:
<target name="junit_bad_classpath">
<mkdir dir="target/junit" />
<junit fork="true">
<classpath>
<pathelement location="lib/*" />
<pathelement location="lib/junit-4.12.jar" />
</classpath>
<formatter type="xml"/>
<batchtest todir="target/junit" >
<fileset dir="src" casesensitive="false">
<include name="**/*Test.class" />
</fileset>
</batchtest>
</junit>
</target>
Unfortunately, I don't have any Windows setup at hand to try this out there. I
might find a way to get hold of a Windows setup and experiment with this a bit,
but it may not be soon.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #4 from space008@gmx.net ---
With <junit fork="true"> is the same problem.
Call junit in command line works with Java 11:
C:\myAntProject>java -cp lib/* org.junit.runner.JUnitCore myProject.MyTest
JUnit version 4.12
.
Time: 0
OK (1 test)
C:\myAntProject>java -version
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #6 from space008@gmx.net ---
Created attachment 36170
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36170&action=edit
two runs with java11; one runs with java8
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #9 from Jaikiran Pai <ja...@apache.org> ---
>> One is to check with the JDK team if this change in which exception gets thrown is intentional (I suspect it isn't, given the javadoc of JarFile). I'll check with the OpenJDK team on this one.
The OpenJDK team has acknowledged that this (change in behaviour) is a bug in
the Java implementation and it is now being tracked at
https://bugs.openjdk.java.net/browse/JDK-8211765.
There's a discussion going on in the OpenJDK dev list on whether the code needs
to be fixed to wrap and throw an IOException or whether the javadoc/API
expectations of these constructors need to be updated to mention that the
java.nio.file.InvalidPathException can be thrown from them. Depending on what
decision is arrived at, we may or may not need a change in Ant project. I'll
keep this issue open until then.
Just to reiterate - As noted in some of our previous comments, I think you can
just get rid of the pathelement that uses lib/* in your example since from what
we have seen/understood so far, even in the "success" case it isn't really
doing anything of value.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62764] junit: pathelement with wildcard fails running on java
11 - InvalidPathException: Illegal char <*>
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #8 from Jaikiran Pai <ja...@apache.org> ---
I think I see what's going on. In Ant, when we are setting up the
AntClassLoader to deal with the JUnit task, we parse the classpath (configured
for the task) and deal with each path element. While doing so if any path
element parsing/handling runs into an IOException (we wrap it into a
BuildException and) silently (without any logs) ignore that specific path
element. This treatment is reserved for IOException that happens during this
parsing of path elements.
It appears to me, that on Windows OS, there's a change in the (implementation)
behaviour in Java across the versions that you are testing against that is
exposing this issue. What's happening, IMO, is that the presence of lib/*
pathelement used to trigger a IOException (when that path was passed to the
java.util.jar.JarFile constructor) and Ant used to catch it and silently ignore
that path and move on. In Java 11, on Windows OS, that same lib/* when passed
to java.util.jar.JarFile constructor now throws a
"java.nio.file.InvalidPathException" which _isn't_ an IOException (or its
subclass) and as a result, Ant, which only treats IOException in a special
manner, ends up propagating this exception and terminating the build.
I think you can easily verify this behaviour on your Windows setup if you run
the following program, both against Java 8 and Java 11:
import java.util.jar.*;
import java.io.*;
public class JarFileTest {
public static void main(final String[] args) throws Exception {
final String tmpDir = System.getProperty("java.io.tmpdir");
try {
final JarFile jarFile = new JarFile(tmpDir +
File.separator + "*");
} catch (IOException ioe) {
System.out.println("Got the expected IOException " +
ioe);
}
}
}
In Java 8, on your setup, I think you will see that System.out.println being
printed whereas in Java 11 you would see the program failing with an exception
stacktrace similar to the one you posted in the description of this bug.
The "solution" in this case might involve a couple of things. One is to check
with the JDK team if this change in which exception gets thrown is intentional
(I suspect it isn't, given the javadoc of JarFile). I'll check with the OpenJDK
team on this one. Second, if it indeed is intentional or a valid expectation to
throw this exception, then we (Ant) might have to deal with it similar to
IOException.
P.S: All this implies is that the lib/* was being ignored (and wasn't playing a
role) in your Java 8 testing, so you can probably just get rid of that
pathelement (as Stefan hinted previously)
--
You are receiving this mail because:
You are the assignee for the bug.