On Tue, 27 Jul 2021 05:43:53 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Securit
On Tue, 27 Jul 2021 03:51:01 GMT, Mandy Chung wrote:
>> Bradford Wetmore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Additional codereview comments
>
> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 76:
>
>> 7
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Tue, 27 Jul 2021 02:50:54 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Securit
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Fri, 4 Jun 2021 10:14:21 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 109:
>>
>>> 107: @SuppressWarnings("removal")
>>> 108: List stack =
>>> 109: AccessController.doPrivileged(pa).walk(Stream::toList);
>>
>
On Thu, 3 Jun 2021 22:48:45 GMT, Mandy Chung wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 14 commits:
>>
>> - More Codereview Comments
>> - Merge branch 'master' into JDK-8267485
>> - Minor typo
>>
On Thu, 3 Jun 2021 22:27:16 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Thu, 3 Jun 2021 21:50:32 GMT, Bradford Wetmore wrote:
>> The latter is probably better so you don't have to move the code; @wangweij
>> used this technique quite a bit for JEP 411 refactoring, see
>> https://github.com/openjdk/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
>
> @seanjmul
On Thu, 3 Jun 2021 21:41:02 GMT, Sean Mullan wrote:
>> For the static initializer that needs updating: I could move the code out
>> of the initializer up to the declaration, or I could create a dummy
>> declaration and then assign to INSTANCE.
>
> The latter is probably better so you don't hav
On Thu, 3 Jun 2021 20:49:27 GMT, Bradford Wetmore wrote:
>> But if you follow my suggestion you can simply apply it to this line:
>>
>>
>> @SuppressWarnings("removal")
>> final List stack =
>> AccessController.doPrivileged(pa).walk(Stream::toList);
>
> For the static initializer that needs upd
On Thu, 3 Jun 2021 17:58:45 GMT, Daniel Fuchs wrote:
>> Unfortunately, we are still calling AccessController, thus the annotation
>> needs to remain.
>
> But if you follow my suggestion you can simply apply it to this line:
>
>
> @SuppressWarnings("removal")
> final List stack =
> AccessContr
On Thu, 3 Jun 2021 17:44:22 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111:
>>
>>> 109: Option.RETAIN_CLASS_REFERENCE)
>>> 110: .walk((s) ->
>>> s.collect(Collectors.toList
On Thu, 3 Jun 2021 17:44:42 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 50:
>>
>>> 48: * @since 1.4
>>> 49: */
>>> 50: @SuppressWarnings("removal")
>>
>> You should remove this annotation now that the dependency on SecurityManager
>>
On Thu, 3 Jun 2021 08:27:14 GMT, Daniel Fuchs wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains eight commits:
>>
>> - Address codereview comments
>> - Merge branch 'master' into JDK-8267485
>> - Merge
On Thu, 3 Jun 2021 14:20:37 GMT, Sean Mullan wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains eight commits:
>>
>> - Address codereview comments
>> - Merge branch 'master' into JDK-8267485
>> - Merge b
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Wed, 2 Jun 2021 18:18:46 GMT, Daniel Fuchs wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains six commits:
>>
>> - Merge branch 'master' into JDK-8267485
>> - Merge branch 'master' into JDK-8267485
>>
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Sat, 22 May 2021 00:20:11 GMT, Bradford Wetmore wrote:
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityMana
The JceSecurityManager is currently a subclass of
java.security.SecurityManager. Now that JEP 411 has been integrated, this
class should be updated to no longer subclass SecurityManager.
The only reason for using SecurityManager to easily get the Class Context (call
stack), but we can achieve
27 matches
Mail list logo