-
Bug
-
Resolution: Unresolved
-
P3
-
16, 17
-
x86_64
-
linux
Ant project's testsuite has recently run into an issue in the JDK 16 EA build 28. This issue is not seen in any other version of JDK (not even in build 26 of JDK 16 EA).
The test that has exposed this issue is one which creates a directory whose filename has a the "ã" character (which represents Latin small letter a with tilde as per the ASCII table[1]). This directory is then fed as the destination directory and source directory to the javac task[2][3]. The javac task is Ant's implementation which internally triggers (via Java reflection, the com.sun.tools.javac.Main#compile method passing it the necessary params some of which contains the directory path with this special character). Things all work fine in all Java versions exception this new build 28 of JDK 16 EA. This one fails with:
Caused by: java.lang.IllegalArgumentException: Error decoding percent encoded characters
at java.base/sun.net.www.ParseUtil.decode(ParseUtil.java:215)
at java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1196)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:485)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:479)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:478)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:447)
at java.base/jdk.internal.loader.URLClassPath$1.next(URLClassPath.java:343)
at java.base/jdk.internal.loader.URLClassPath$1.hasMoreElements(URLClassPath.java:354)
at java.base/java.net.URLClassLoader$3$1.run(URLClassLoader.java:648)
at java.base/java.net.URLClassLoader$3$1.run(URLClassLoader.java:646)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at java.base/java.net.URLClassLoader$3.next(URLClassLoader.java:645)
at java.base/java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:670)
at java.base/java.lang.CompoundEnumeration.next(ClassLoader.java:2719)
at java.base/java.lang.CompoundEnumeration.hasMoreElements(ClassLoader.java:2728)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1202)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1383)
at jdk.compiler/com.sun.tools.javac.api.BasicJavacTask.initPlugins(BasicJavacTask.java:219)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:292)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
... 45 more
The complete run along with the logs is available at [4]
This happens only on our CI setup which runs Linux. I locally don't have a Linux box to verify if it fails on on Linux boxes. This passes on my local macOS box.
Some possibly relevant system properties from that CI setup are as follows:
<property name="file.encoding" value="ISO-8859-1"/>
<property name="java.version" value="16-ea"/>
<property name="java.vm.specification.name" value="Java Virtual Machine Specification"/>
<property name="java.library.path" value="/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib"/>
<property name="java.vendor" value="Oracle Corporation"/>
<property name="sun.io.unicode.encoding" value="UnicodeLittle"/>
<property name="os.name" value="Linux"/>
<property name="sun.jnu.encoding" value="ISO-8859-1"/>
[1] https://www.ascii-code.com/
[2] https://github.com/apache/ant/blob/master/src/etc/testcases/core/antclassloader.xml#L22
[3] https://github.com/apache/ant/blob/master/src/etc/testcases/core/antclassloader.xml#L60
[4] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk16_ea,label_exp=ubuntu/13/
The test that has exposed this issue is one which creates a directory whose filename has a the "ã" character (which represents Latin small letter a with tilde as per the ASCII table[1]). This directory is then fed as the destination directory and source directory to the javac task[2][3]. The javac task is Ant's implementation which internally triggers (via Java reflection, the com.sun.tools.javac.Main#compile method passing it the necessary params some of which contains the directory path with this special character). Things all work fine in all Java versions exception this new build 28 of JDK 16 EA. This one fails with:
Caused by: java.lang.IllegalArgumentException: Error decoding percent encoded characters
at java.base/sun.net.www.ParseUtil.decode(ParseUtil.java:215)
at java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1196)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:485)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:479)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:478)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:447)
at java.base/jdk.internal.loader.URLClassPath$1.next(URLClassPath.java:343)
at java.base/jdk.internal.loader.URLClassPath$1.hasMoreElements(URLClassPath.java:354)
at java.base/java.net.URLClassLoader$3$1.run(URLClassLoader.java:648)
at java.base/java.net.URLClassLoader$3$1.run(URLClassLoader.java:646)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at java.base/java.net.URLClassLoader$3.next(URLClassLoader.java:645)
at java.base/java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:670)
at java.base/java.lang.CompoundEnumeration.next(ClassLoader.java:2719)
at java.base/java.lang.CompoundEnumeration.hasMoreElements(ClassLoader.java:2728)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1202)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1383)
at jdk.compiler/com.sun.tools.javac.api.BasicJavacTask.initPlugins(BasicJavacTask.java:219)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:292)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
... 45 more
The complete run along with the logs is available at [4]
This happens only on our CI setup which runs Linux. I locally don't have a Linux box to verify if it fails on on Linux boxes. This passes on my local macOS box.
Some possibly relevant system properties from that CI setup are as follows:
<property name="file.encoding" value="ISO-8859-1"/>
<property name="java.version" value="16-ea"/>
<property name="java.vm.specification.name" value="Java Virtual Machine Specification"/>
<property name="java.library.path" value="/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib"/>
<property name="java.vendor" value="Oracle Corporation"/>
<property name="sun.io.unicode.encoding" value="UnicodeLittle"/>
<property name="os.name" value="Linux"/>
<property name="sun.jnu.encoding" value="ISO-8859-1"/>
[1] https://www.ascii-code.com/
[2] https://github.com/apache/ant/blob/master/src/etc/testcases/core/antclassloader.xml#L22
[3] https://github.com/apache/ant/blob/master/src/etc/testcases/core/antclassloader.xml#L60
[4] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk16_ea,label_exp=ubuntu/13/
- blocks
-
JDK-8259646 JavaCompiler still uses File API instead of Path API in a specific case (Round 2)
- Open
- relates to
-
JDK-8344908 URLClassPath should not propagate IllegalArgumentException when finding resources in classpath URLs
- Resolved
-
JDK-8259645 Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case
- Closed