RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v2]

[Bernd]

On Mon, 25 Oct 2021 17:58:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/Subject.java line 325:
>> 
>>> 323: 
>>> 324:     // Store the current subject to a ThreadLocal when a system property is set.
>>> 325:     private static final boolean USE_TL = "true".equalsIgnoreCase(
>> 
>> Can you use GetBooleanAction.privilegedGetProperty instead?
>
> Sure, I can. I was testing the default value to "false" at some time and found `"true".equals` and `!"false".equals` symmetric and good-looking. :-)

It probably doesn’t matter to have the Logic centralized, just looked a bit hardcoded (who knows if yes/no/1/0 is wanted as well ,).

>> src/java.base/share/classes/javax/security/auth/Subject.java line 349:
>> 
>>> 347:      * the one of its parent thread, and will not change even if
>>> 348:      * its parent thread's current subject is changed to another value.
>>> 349:      *
>> 
>> Should it say something about installing or unsettling the subject in a nested execution (if it can be restricted)?
>
> I said "After {@code action} is finished, the current subject is reset to its previous value". Is that what you meant?

My question was more along the line of Post-Security-manager. Will you always be able to call Subject.doAs - especially with null? And if this can already be speced if it might be rejected or not… (the „after finished“ is well documented)

>> src/java.base/share/classes/javax/security/auth/Subject.java line 475:
>> 
>>> 473:      *       call {@link #callAs} to perform the same work, which is based on
>>> 474:      *       {@link #doAs(Subject, PrivilegedExceptionAction)}
>>> 475:      *       by default in this implementation.
>> 
>> Should it also mention that unless you define the TL system property it will still affect the new current() call? (Just to introduce the concept by repetition).
>
> I just don't want to touch existing spec. Even for `doAs`, I only said "callAs is based on doAs by default" and didn't went out explaining what is NOT by default. Is that OK?

Yes good reason not to change it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024