On Mon, 15 Mar 2021 23:31:33 GMT, Valerie Peng wrote:
>> I would definitely not call `new SecureRandom()` each time as that can have
>> real performance problems (especially on systems which pull from
>> `/dev/random` and may not have hardware entropy). The synchronization
>> worries me too.
On Mon, 15 Mar 2021 22:11:51 GMT, SalusaSecondus
wrote:
>> Cipher and KeyPairGenerator could be used a lot in TLS context. The
>> synchronization may impact in some circumstances. Supporting dynamic
>> configuration could be error-prone. For example, one thread to set the
>> providers,
On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Mon, 15 Mar 2021 21:37:59 GMT, SalusaSecondus
wrote:
>> test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java
>> line 80:
>>
>>> 78: // === Case 1: private key is RSAPrivateCrtKey, expected spec
>>> is RSAPrivateKeySpec
>>> 79: // === Expected: return
On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Mon, 15 Mar 2021 21:47:28 GMT, Сергей Цыпанов
wrote:
>> Hello,
>>
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
>> joined Strings.
>>
>> This applies for the cases when all joined Strings as well as delimiter,
>> prefix and suffix contain only ASCII symbols.
On Mon, 15 Mar 2021 21:36:08 GMT, Xue-Lei Andrew Fan wrote:
>> Since 5 classes have init() calls that would be acquiring this lock,
>> something that could be independent would be better. Calling "new
>> SecureRandom()" may or may not be better, but hope it wouldn't lock over
>> operations
On Mon, 15 Mar 2021 21:30:57 GMT, Valerie Peng wrote:
> P11RSAKeyFactory.java should also be included into this fix as it's subject
> to the same RSAPrivateKeySpec vs RSAPrivateCrtKeySpec issue.
Thank you. We'll fix this.
>
> My personal take is that the isAssignableFrom() call may be more
On Mon, 15 Mar 2021 20:54:54 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
> Hello,
>
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
> joined Strings.
>
> This applies for the cases when all joined Strings as well as delimiter,
> prefix and suffix contain only ASCII symbols.
>
> As a result when `StringJoiner.toString()` is called `byte[]`
On Mon, 15 Mar 2021 21:35:16 GMT, Valerie Peng wrote:
>> Ziyi Luo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add one test case for the regression fixed by 8263404
>
>
On Fri, 12 Mar 2021 22:00:18 GMT, Ziyi Luo wrote:
>> This is a P2 regression introduced by JDK-8254717.
>>
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the
>> KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is
>> described as follow:
>>
>>
On Sat, 13 Mar 2021 00:37:41 GMT, SalusaSecondus
wrote:
>> I still cannot understand why CRT is always preferred. The original
>> implementation also hadn't done that.
>
> I believe that the original implementation intended to do this but made a
> mistake. This is why the original
On Mon, 15 Mar 2021 21:31:12 GMT, Anthony Scarpino
wrote:
>> It depends, this may not be a "hot area" where there is a lot of contention?
>> Or do you feel maybe we should just go with the slower "new SecureRandom()"
>> call for each affected class? I am on the fence actually.
>
> Since 5
On Mon, 15 Mar 2021 21:05:36 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 62:
>>
>>> 60: private static SecureRandom instance = new SecureRandom();
>>> 61: public static SecureRandom instance(boolean checkConfig) {
>>> 62:
On Mon, 15 Mar 2021 20:55:24 GMT, Xue-Lei Andrew Fan wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected
On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng wrote:
> Can someone help review this somewhat trivial change?
>
> Updated JCAUtil class to return the cached SecureRandom object only when the
> provider configuration has not changed.
> Added a regression test to check the affected classes,
On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng wrote:
> Can someone help review this somewhat trivial change?
>
> Updated JCAUtil class to return the cached SecureRandom object only when the
> provider configuration has not changed.
> Added a regression test to check the affected classes,
On Mon, 15 Mar 2021 18:00:27 GMT, Сергей Цыпанов
wrote:
>> Hello,
>>
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
>> joined Strings.
>>
>> This applies for the cases when all joined Strings as well as delimiter,
>> prefix and suffix contain only ASCII symbols.
On Fri, 26 Feb 2021 13:15:28 GMT, Rémi Forax
wrote:
>> Looking for some final code reviews.
>
> I still don't like the fact that the factory uses reflection but i don't see
> how to do better
This is now looking very nicely structured.
The only thing i am unsure are the details around
Can someone help review this somewhat trivial change?
Updated JCAUtil class to return the cached SecureRandom object only when the
provider configuration has not changed.
Added a regression test to check the affected classes, i.e.
AlgorithmParameterGenerator, KeyPairGenerator, Cipher,
On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 114 commits:
>>
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-8263002: bsd_aarch64 part
>> - Merge
On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson wrote:
>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block
>> belongs to Thread for now. Since W^X is an attribute of any operating system
>> thread, I assumed Thread to be the right place for W^X bookkeeping.
>>
>>
On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote:
>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to
>> define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?
I've tried to implement the suggestion, but it pulled more
On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov
wrote:
>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall -
>> have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>>
On Mon, 15 Mar 2021 14:07:29 GMT, Claes Redestad wrote:
>> I was thinking about `StringBuilder` at the very beginning but then decided
>> to have no bounds checks and reallocations. Indeed from maintainability
>> point of view your solution is much more attractive. I have one minor
>> comment
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
> Hello,
>
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
> joined Strings.
>
> This applies for the cases when all joined Strings as well as delimiter,
> prefix and suffix contain only ASCII symbols.
>
> As a result when `StringJoiner.toString()` is called `byte[]`
On Thu, 25 Feb 2021 20:56:42 GMT, Weijun Wang wrote:
> When default_tkt_enctypes or default_tgs_enctypes, use the value of
> permitted_enctypes if it exists.
>
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8262391 and release note at
>
The changes to Cache.java look fine, but please include CacheBench.java. I'd
like to see 11u to stand on its own without reference to later releases, plus I
believe the 11u maintainers prefer to backport as much of a patch as possible.
Thanks,
Paul
-Original Message-
From:
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272 Refactor I/O stream copying to use
InputStream.transferTo/readAllBytes
On Mon, 15 Mar 2021 13:52:57 GMT, Сергей Цыпанов
wrote:
>> A less intrusive alternative would be to use a `StringBuilder`, see changes
>> in this branch:
>> https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1
>> (I adapted your StringJoinerBenchmark to work
On Mon, 15 Mar 2021 12:36:24 GMT, Claes Redestad wrote:
>> Hi @cl4es,
>>> Some of these changes conflict with #2334, which suggest removing the
>>> `coder` and `isLatin1` methods from `String`.
>>
>> I've checked out Aleksey's branch and applied my changes onto it, the only
>> thing that I
On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov
wrote:
>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall -
>> have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>>
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
On Thu, 18 Feb 2021 20:14:12 GMT, Сергей Цыпанов
wrote:
>> Some of these changes conflict with #2334, which suggest removing the
>> `coder` and `isLatin1` methods from `String`.
>>
>> As a more general point I think it would be good to explore options that
>> does not increase leakage of
On Wed, 18 Nov 2020 13:45:46 GMT, Jim Laskey wrote:
>> Need rebase
>
> Created new PR because of forced push:
> https://github.com/openjdk/jdk/pull/1292
LGTM
-
PR: https://git.openjdk.java.net/jdk/pull/1273
On Fri, 12 Mar 2021 09:22:40 GMT, Aleksey Shipilev wrote:
> SonarCloud actually found this:
> Verify this is the index that was intended; it was already set before.
>
>
> public byte[][] toByteArray() {
> byte[][] result = new byte[nameStrings.length][];
> for (int i =
38 matches
Mail list logo
