On Thu, 28 May 2026 19:15:32 GMT, Ashay Rane <[email protected]> wrote:
>> Although the original implementation of `JLI_Open()` borrowed from the >> code in src/hotspot/os/windows/os_windows.cpp, the improvements to >> os_windows.cpp don't seem to have been applied to java_md.c, causing >> some tests to fail when the path to JAR files is longer than `MAXPATH` >> (i.e. 260) characters on Windows (see associated JBS issue 8385024 for >> details). Since `JLI_Open()` is not just invoked inside tests, this is >> not a test-specific issue, so fixing the test is not the right solution. >> >> This patch applies the recent changes from os_windows.cpp to java_md.c >> so that `JLI_Open()` can correctly handle longer than `MAXPATH` paths. >> The new code is almost the same as that in `wide_abs_unc_path()` in >> os_windows.cpp, except that the code in java_md.c uses `JLI_MemAlloc()` >> and `JLI_MemFree()` for memory allocation and deallocation. >> >> Although it would be ideal to have just one implementation between >> HotSpot and the launcher, the dependencies of the two components >> prevents us from having a single implementation. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Ashay Rane has updated the pull request incrementally with one additional > commit since the last revision: > > Add test to exercise the change > > This patch adds a new test so that the relative path (which becomes the > argument to `JLI_Open()`) is shorter than `MAX_PATH` but that the > absolute path (that is resolved inside `_open()`) is longer than > `MAX_PATH`. To construct such a case, the test first probes the length > of the current working directory and then creates additional > subdirectories to meet the desired constraint. Sorry about the delay, I had to attend to some other things. Thanks for the suggestion, I hadn't thought of such a case. I've added a test case where the relative path (which becomes the argument to `JLI_Open()`) is shorter than 260 characters but the absolute path (which gets resolved inside `_open()`) is longer than 260 characters. I checked that the test fails without the changes in this PR: == before == Test void Arrrghs.testLongResolvedPathJarFile() throws java.io.IOException failed: java.lang.reflect.InvocationTargetException ----begin detailed exceptions---- java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:583) at TestHelper.run(TestHelper.java:202) at Arrrghs.main(Arrrghs.java:742) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:583) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1527) Caused by: java.lang.RuntimeException: testLongResolvedPathJarFile failed: java.io.PrintWriter@43f6863f at Arrrghs.testLongResolvedPathJarFile(Arrrghs.java:543) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more ----end detailed exceptions---- ... Total: Passed: 6, Failed 1 java.lang.RuntimeException: Tests failed: 1 at TestHelper.run(TestHelper.java:221) at Arrrghs.main(Arrrghs.java:742) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:583) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1527) == after == Passed: 7, Failed: 0, ExitValue: 0 Total: Passed: 7, Failed 0 All tests pass STATUS:Passed. I did have to update the test so that it would throw an exception upon failure, otherwise, it wasn't clear which test failed (see commit message of the most recent commit for details). ------------- PR Comment: https://git.openjdk.org/jdk/pull/31209#issuecomment-4567773490
