https://bz.apache.org/bugzilla/show_bug.cgi?id=62764
--- Comment #8 from Jaikiran Pai <jaiki...@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.
