Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SecurityManager is deprecated for removal #1636

Open
netdpb opened this issue Dec 3, 2024 · 6 comments · May be fixed by #1638
Open

SecurityManager is deprecated for removal #1636

netdpb opened this issue Dec 3, 2024 · 6 comments · May be fixed by #1638

Comments

@netdpb
Copy link

netdpb commented Dec 3, 2024

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
Copy link

cushon commented Dec 3, 2024

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
Copy link
Member

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
Copy link

cushon commented Dec 3, 2024

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

@matthiasblaesing matthiasblaesing changed the title SecurityManager is deprecated and will be removed in JDK 24 SecurityManager is deprecated for removal Dec 4, 2024
@dblock
Copy link
Member

dblock commented Dec 4, 2024

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

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

@reta
Copy link

reta commented Dec 5, 2024

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 added a commit to matthiasblaesing/jna that referenced this issue Dec 8, 2024
@matthiasblaesing
Replace usage of SecurityManager and AccessController#doPrivileged
2277556 
The SecurityManager class is deprecated for removal since JDK 17. Its
getClassContext method is used to optain the calling class when
Native#register and Native#unregister are used without the target class
being passed in. With JDK 9 the StalkWalker was introduced to make
that information available. This change makes both methods available
using method handles and prefers the StalkWalker codepath as that is
the path expected to be invoked in most cases (on JDK 9+).

The AccessController#doProvileged call is replaced by a method handle,
assuming, that in an environment where WebStart is available,
AccessController is also available.

Closes: java-native-access#1636
@matthiasblaesing matthiasblaesing linked a pull request Dec 8, 2024 that will close this issue
Open
@matthiasblaesing
Copy link
Member

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

matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Dec 12, 2024
@matthiasblaesing
Replace usage of SecurityManager and AccessController#doPrivileged
69955bd 
The SecurityManager class is deprecated for removal since JDK 17. Its
getClassContext method is used to optain the calling class when
Native#register and Native#unregister are used without the target class
being passed in. With JDK 9 the StalkWalker was introduced to make
that information available. This change makes both methods available
using method handles and prefers the StalkWalker codepath as that is
the path expected to be invoked in most cases (on JDK 9+).

The AccessController#doProvileged call is replaced by a method handle,
assuming, that in an environment where WebStart is available,
AccessController is also available.

Closes: java-native-access#1636
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Replace usage of SecurityManager and AccessController#doPrivileged matthiasblaesing/jna
5 participants
@cushon @reta @dblock @matthiasblaesing @netdpb