On Mon, 25 Oct 2021 17:58:15 GMT, Weijun Wang <wei...@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

Reply via email to