Java warning: <T>doAs(Subject,PrivilegedAction<T>) in Subject has been deprecated and marked for removal

[esabol]

I noticed that the latest Appveyor builds are emitting this warning: <T>doAs(Subject,PrivilegedAction<T>) in Subject has been deprecated and marked for removal.

doAs is used in three places in the code:

davmail/src/java/davmail/http/KerberosHelper.java

Line 201 in 4c8b688

return Subject.doAs(clientLoginContext.getSubject(), (PrivilegedAction<Object>) () -> {

davmail/src/java/davmail/http/KerberosHelper.java

Line 286 in 4c8b688

Object result = Subject.doAs(serverLoginContext.getSubject(), (PrivilegedAction<Object>) () -> {

davmail/src/java/davmail/http/DavMailSPNegoScheme.java

Line 123 in 4c8b688

return Subject.doAs(clientLoginContext.getSubject(), (PrivilegedAction<Object>) () -> {

See https://docs.oracle.com/en/java/javase/23/security/migrating-deprecated-removal-methods-subject-getsubject-and-subject-doas-subject-current-and-s.html for details and advice on what the code the code should be changed to.

https://bugs.openjdk.org/browse/JDK-8275529 is apparently related to this deprecation.

Could add @SuppressWarnings("removal") for the near-term if there's a need to support older JDKs that don't support the new Subject.current().callAs() method?

Reason for deprecation:

This deprecation is due to the reliance on the SecurityManager which is also deprecated and considered outdated in modern Java security practices.

What to do instead:

To achieve similar functionality, use the Subject.current().callAs() method which is the recommended replacement for doAs.

Example of how to migrate:

// Old code using deprecated doAs
Subject subject = ...;
String result = subject.doAs(subject, new PrivilegedAction<String>() {
    public String run() {
        // privileged action
        return "Some privileged data";
    }
});

// Updated code using callAs
Subject subject = Subject.current(); // Get the current subject
String result = subject.callAs(() -> {
    // privileged action
    return "Some privileged data";
});

[mguessan]

Noticed this, issue is suggested replacement is @SInCE 18, so we would need to drop support for anything before JDK 18.

... or introduce some kind of conditional build which is a pain to maintain.

[esabol]

@mguessan wrote:

Noticed this, issue is suggested replacement is @SInCE 18, so we would need to drop support for anything before JDK 18.

... or introduce some kind of conditional build which is a pain to maintain.

Yeah, I figured that. So @SuppressWarnings("removal") then?