SimpleMappedReader uses sun.misc.Unsafe.invokeCleaner: JEP 498 warning on JDK 24+, removal planned #774

SimpleMappedReader unmaps its buffer through sun.misc.Unsafe.invokeCleaner (jvector-base/src/main/java/io/github/jbellis/jvector/disk/SimpleMappedReader.java, getUnsafe() and the cleaner call in SimpleMappedReader$Supplier). On JDK 24 and later this is a terminally deprecated memory-access method (JEP 498), so the first call prints this on the process's initial stderr:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::invokeCleaner has been called by io.github.jbellis.jvector.disk.SimpleMappedReader$Supplier (file:/.../jvector-4.0.2.jar)
WARNING: Please consider reporting this to the maintainers of class io.github.jbellis.jvector.disk.SimpleMappedReader$Supplier
WARNING: sun.misc.Unsafe::invokeCleaner will be removed in a future release

Two consequences for embedders:

1. The method is scheduled for removal, after which the unmap path stops working (or needs --sun-misc-unsafe-memory-access=allow until then).
2. The JDK writes this warning through jdk.internal.misc.VM.initialErr(), a copy of stderr taken before application code runs, which System.setErr does not change. I embed ArcadeDB (which uses jvector for its vector index) in Python through JPype and as a GraalVM native image. On Windows, when the host process later redirects fd 2, the stale stderr handle can be reused by a newly opened file, and these four lines ended up inside a database file. I have fixed my side by redirecting System.initialErr too (JVM build: Java System.out/System.err go to a file the library owns when the console is off (Windows data corruption) ArcadeData/arcadedb-python#88), and the native image case is in progress.

Would you consider unmapping with the FFM API (an Arena-scoped MemorySegment in the Java 22+ build), or dropping the explicit unmap where the JDK cleaner is enough? I can test a change against my embedding on Linux, macOS and Windows.