<div dir="ltr"><div><div><div>Hello everyone,<br><br>In JetBrains, we are working on the improvement of interaction with WSL. Due to a bug in Windows, certain interaction with WSL filesystem is unreasonably slow: <a href="https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL">https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL</a><br>The reproducer uses plain Java IO API, so the problem is not in our codebase. We think that it is possible to fix it by using Java NIO with a custom `java.nio.file.spi.FileSystemProvider` (which we also need for other purposes), but there is no way of currently doing it for `java.util.zip.ZipFile`.<br><br>We have an idea of a fix: one can observe that `ZipFile` uses `java.io.RandomAccessFile` internally, which has a similar interface to `SeekableByteChannel`. We attempted to patch JDK in order for `ZipFile` to use `FileChannel` (<a href="https://github.com/JetBrains/JetBrainsRuntime/pull/413">https://github.com/JetBrains/JetBrainsRuntime/pull/413</a>), and noticed the following issues:<br>1. On Windows, `RandomAccessFile` opens a file without `FILE_SHARE_DELETE` mode. `FileChannel`, on the contrary, does open a file in this mode, which results in subtle differences reflected in the test `TestZipError.java`. See more in <a href="https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753">https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753</a> . I suspect that it is possible to fix by the use of `ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more complicated.<br>2. A more serious issue, `FileChannel` performs reading and writing using direct buffers. It breaks an (implicit?) contract that by default JVM does not allocate memory-mapped files, as reflected by the test `LimitDirectMemory.java`.<br><br>Currently, we are going to apply the proposed patch to our builds, but we would like to hear your thoughts on whether it is possible to include it in the upstream of OpenJDK.<br><br></div>Best regards,<br></div>Konstantin Nisht,<br></div>JetBrains.<br></div>