SecurityManager is deprecated for removal

[netdpb]

SecurityManager is deprecated for removal in JDK 24, but it's used in Native.getCallingClass(). That usage has to be removed in order for JNA to be compatible with newer versions of Java.

[cushon]

It's being used for SecurityManager#getClassContext. For Java 9 and newer, this could be migrated to use java.lang.StackWalker#getCallerClass instead, e.g.:

StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass()

That would require some extra work to support earlier Java versions, but it could potentially use reflection to call that API on Java 9+, or use a Multi-Release jar.

[matthiasblaesing]

Just to get some relaxation in here: The current JDK 24-EA happily lets you create a subclass of SecurityManager and call getClassContext on it. So world will not end when JDK24 is released.

I think the relevant part is:

We will leave a minimal version of the java.lang.SecurityManager class in place for compatibility with the few applications, libraries, and tools that still use it. We will remove this class in a future release.

[cushon]

Thanks! I'd missed that: https://github.com/openjdk/jdk/blob/05ee562a38bf7325becdd04f2e9d3238b95a4cb0/src/java.base/share/classes/java/lang/SecurityManager.java#L66-L71

[dblock]

A lot of relevant discussion here: opensearch-project/OpenSearch#1687

OpenSearch uses JNA and JSM extensively, cc: @reta.

[reta]

OpenSearch uses JNA and JSM extensively, cc: @reta.

Thanks @dblock , java.lang.StackWalker is what we are looking for to get the caller (but OS has JDK-11 baseline, so no need to fallback to MH / reflection)

[matthiasblaesing]

If anyone is interested, PR #1638 is available with a MH based approach to replace SecurityManager and AccessController.