Hello Fabian,
There are two issues here. The first is - if "java" is launched with a
classpath containing a path which has emoji character in it then that
leads to an exception causing the launch to fail.
For example, if you have a "Foo.class" in /tmp/ascii-dir and you
currently are in "<dir-with-emoji-char>" and you do:
<dir-with-emoji-char> $> java -cp .:/tmp/ascii-dir Foo
Then that leads to the following exception:
Error: A JNI error has occurred, please check your installation and try
again
Exception in thread "main" java.lang.IllegalArgumentException: Error
decoding percent encoded characters
at java.base/sun.net.www.ParseUtil.decode(ParseUtil.java:221)
at
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1030)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:483)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:477)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:476)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444)
at
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:315)
at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:757)
...
The second issue is that due to an internal implementation detail of
jdk.internal.loader.URLClassPath it cannot handle paths that have an
emoji character in it. What that implies is that it cannot serve any
resources from such paths.
The first issue which causes the launch to fail with an exception is a
straightforward bug that needs fixing. A URLClassPath can have multiple
URLs as the classpath and it is implemented in a way to not throw
exceptions if any of those URLs are unusable. We do have a bug in this
specific case where this unusable URL raises the exception from the
URLClassPath code. That should be addressed through
https://bugs.openjdk.org/browse/JDK-8344908.
The second issue to enhance URLClassPath to be able to support serving
resources from paths containing emojis (for example) is more involved
and ties into https://bugs.openjdk.org/browse/JDK-8258246. I will have
to refresh myself with that issue and check with others on what can be
done for that (if anything).
-Jaikiran
On 22/11/24 11:57 pm, Fabian Meumertzheim wrote:
I just observed that the java launcher fails to run (any) Java program
on macOS if executed from a working directory that contains a
character with a 4-byte UTF-8 encoding (say an emoji).
While it does seem related to JDK-8258246, which was considered to be
caused by more general issues with legacy URL/URI conversion, I
believe that my current issue comes down to just
sun.net.www.ParseUtil.decode(sun.net.www.ParseUtil.fileToEncodedURL(f))
failing for any File f with such a character in its path.
Since sun.net.www.ParseUtil.fileToEncodedURL seems to have its single
call site in URLClassPath, which is the source of the issue, I wonder
whether this could be fixed in a more targeted manner without
incurring the high risks alluded to in JDK-8258246. For example,
replacing the URL encoding logic with f.toPath().toUri().toURL() does
seem to resolve the issue.
Is the latest comment on JDK-8258246 still the plan or would a
separate bug report for this more targeted issue be welcome?
Fabian
