Since https://openjdk.org/jeps/498 memory-access methods in sun.misc.Unsafe are warned:

```java
import sun.misc.Unsafe;
import java.lang.reflect.Field;

public class MyLibraryWithOffHeap {

    public static void main(String[] args) {
        long pointer = UNSAFE.allocateMemory(8);
        System.out.println("pointer = " + pointer);
        // Imagine some more useful logic with off-heap memory, just keeping the example short here
    }

    private static final Unsafe UNSAFE = getUnsafe();

    @SuppressWarnings("restriction")
    private static Unsafe getUnsafe() {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            return (Unsafe) field.get(null);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new Error(e);
        }
    }

}
```
```
$ java MyLibraryWithOffHeap
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::allocateMemory has been called by MyLibraryWithOffHeap (file:...)
WARNING: Please consider reporting this to the maintainers of class MyLibraryWithOffHeap
WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future release
pointer = 139857021917392
```

For on-heap memory, the replacement VarHandle is available since a long time, JDK 9, so that should be feasible to migrate to.

However, for off-heap memory, the replacement is the Foreign Function & Memory API (JEP 454), which is only available since JDK 22.

This means the Unsafe off-heap access runtime warnings are not actionable for libraries (and every warning should be actionable), most libraries need to run at least on the latest LTS JDK, that is JDK 21, which doesn't have the Foreign Function & Memory API.
Hence I think the warning is too soon, it should be JDK 25 at earliest, and maybe even the LTS after 25, to allow libraries to e.g. support 21 & 25 at the same time.

Requiring all these libraries (so many use Unsafe: https://github.com/search?q=sun.misc.Unsafe+language%3AJava+&type=code although that doesn't differentiate on-heap/off-heap) to build an abstraction layer to use either Unsafe or Panama based on the JDK runtime version and use multi-release jars seems unreasonable: that's a lot of effort and complications. It's a lot of wasted time for everyone involved.

Doing nothing is one option, but then all users of the library need to pass --sun-misc-unsafe-memory-access=allow and the warning doesn't even mention that. And it will annoy every user of a library using Unsafe, so probably most Java applications out there.
So one probable effect of this warning is most java application will add --sun-misc-unsafe-memory-access=allow. Is that a desirable outcome?

Another option might be to use jdk.internal.misc.Unsafe instead (obviously not ideal), which requires flags, but since a flag is required to silence these warnings anyway maybe not the worse trade-off?

Using JNI seems a no-go because it would add a huge overhead for each off-heap access and it also produces runtime warnings.

Are there any other solutions that I'm missing?