On Fri, 5 Aug 2022 21:49:01 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8290975
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> comment applies to two files
Thanks Sean and Brad for the review!
-
On Fri, 5 Aug 2022 21:49:01 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8290975
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> comment applies to two files
LGTM.
-
Marked as reviewed by wet
> https://bugs.openjdk.org/browse/JDK-8290975
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
comment applies to two files
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9664/files
- new: https://git.openjdk.org/j
> https://bugs.openjdk.org/browse/JDK-8290975
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
comment from sean
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9664/files
- new: https://git.openjdk.org/jdk/pull/966
On Fri, 5 Aug 2022 14:09:18 GMT, Mark Powers wrote:
>> Yes but `defaultName` (like `prompt`) should never change once the object is
>> constructed. So it seems inconsistent not to also mark it final (and if
>> necessary, set it to a default value (`null`) in the constructors).
>
> Agreed. I'll
On Fri, 5 Aug 2022 14:29:38 GMT, Mark Powers wrote:
>> I'll file a bug later today and add to this bug report.
>
> You must mean sun.security.util.Debug.
JDK-8291974
-
PR: https://git.openjdk.org/jdk/pull/9664
On Thu, 4 Aug 2022 20:20:35 GMT, Mark Powers wrote:
>> src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java
>> line 130:
>>
>>> 128: * @serial
>>> 129: */
>>> 130: private final boolean testing = false;
>>
>> This should really use java.security.debug
On Tue, 19 Jul 2022 20:55:54 GMT, David Schlosnagle wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyrights, apply consistent settings to PermissionsImplies
>
> test/micro/org/openjdk/bench/java/security/SSLHa
> - Reduce forks, iteration, runtime to reduce runtime while maintaining high
> data quality on typical benchmarking hosts.
>
> Reduces runtime from estimated 10+ hours to 54 minutes.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 5 Aug 2022 10:04:43 GMT, Sean Mullan wrote:
>> I verified the error message happens when `defaultName` is final.
>
> Yes but `defaultName` (like `prompt`) should never change once the object is
> constructed. So it seems inconsistent not to also mark it final (and if
> necessary, set it
Fix `SSLEngineService` test class to make sure it does not discard any network
data between `handshaking` and `receive`.
With TLS1.3 the client starts sending application data immediately after
sending the Finished message. The server may read some of that data in the
`handshaking` method. This
On Thu, 4 Aug 2022 17:03:37 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java
>> line 46:
>>
>>> 44: * @since 1.4
>>> 45: */
>>> 46: private final String prompt;
>>
>> I think you can also mark `defaultText` final.
>
>
On Thu, 4 Aug 2022 20:21:44 GMT, Mark Powers wrote:
>> First constructor doesn't set defaultName (or inputName), so there will be a
>> error "might not have been initialized".
>
> I verified the error message happens when `defaultName` is final.
Yes but `defaultName` (like `prompt`) should neve
On Thu, 4 Aug 2022 15:55:38 GMT, Alan Bateman wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unused JLA, SharedSecrets, added @enablePreview test annotation
>
> test/jdk/jdk/internal/misc/TerminatingThread
> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
> when used internally in JDK for per-carrier-thread caches of native
> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
> TerminatingThreadLocal(s) are not registered with the carrier thread for t
On Thu, 4 Aug 2022 15:54:29 GMT, Alan Bateman wrote:
>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
>> when used internally in JDK for per-carrier-thread caches of native
>> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
>> TerminatingThre
16 matches
Mail list logo
