On 3/12/19 11:54 AM, Severin Gehwolf wrote:
> On Mon, 2019-03-11 at 07:50 +, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/
This looks good, except the change in KdcPolicy.java. See b
On 3/14/19 3:31 AM, Andrew John Hughes wrote:
> I've filed
> https://bugs.openjdk.java.net/browse/JDK-8220641
Yes, let's RFR and push that too.
> for that issue and generated a new webrev for 8175120:
>
> https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/
Looks good!
-Aleksey
On 3/15/19 5:55 AM, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
Looks good, ship it.
-Aleksey
signature.asc
Description: OpenPGP digital signature
On 5/16/19 7:51 PM, Severin Gehwolf wrote:
> Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't
> seems to have this issue as with the TLS 1.3 feature (JDK-8196584)
> SessionId.hashCode() got changed to use Arrays.hashCode() already.
>
> webrev: http://cr.openjdk.java.net/~sge
Recent push broke at least x86_32:
https://bugs.openjdk.java.net/browse/JDK-8225695
Fix:
http://cr.openjdk.java.net/~shade/8225695/webrev.01/
Pretty sure format specifiers are still incorrect for 32-bit, but default build
does not touch the
TRACE statements. Feel free to amend the patch and/
On 6/13/19 12:39 PM, Alan Bateman wrote:
> On 13/06/2019 11:28, Aleksey Shipilev wrote:
>> Recent push broke at least x86_32:
>> https://bugs.openjdk.java.net/browse/JDK-8225695
>>
>> Fix:
>> http://cr.openjdk.java.net/~shade/8225695/webrev.01/
>>
>
On 6/13/19 1:14 PM, Alan Bateman wrote:
> On 13/06/2019 12:03, Aleksey Shipilev wrote:
>> Maybe? That header is from another library/module, though: libjava, and we
>> are at libj2pkcs11. I am
>> a bit worried about introducing this dependency. It is probably fine to
&g
On 6/13/19 1:35 PM, Alan Bateman wrote:
> I think it looks a bit better as it avoids needing to stop and wonder if
> uintptr_t is correct or not.
All right. Here is the updated patch:
http://cr.openjdk.java.net/~shade/8225695/webrev.02/
Testing: {x86_64, x86_32} builds; jdk-submit (running)
-
On 6/13/19 8:05 PM, Alan Bateman wrote:
> On 13/06/2019 18:15, Aleksey Shipilev wrote:
>> On 6/13/19 1:35 PM, Alan Bateman wrote:
>>> I think it looks a bit better as it avoids needing to stop and wonder if
>>> uintptr_t is correct or
>>> not.
>> All ri
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API
> in 3 main ways:
> * first, by
On Thu, 8 Oct 2020 10:29:24 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the
>> API in 3 main ways:
>> * firs
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first,
On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote:
> #8599 would add a new warning. This address the conversions in the
> microbenchmark component by means of making the types precise or adding
> explicit casts. There's quite a few changes in the ByteBuffers benchmarks,
> but the real cha
On Wed, 11 May 2022 15:47:29 GMT, Claes Redestad wrote:
>> #8599 would add a new warning. This address the conversions in the
>> microbenchmark component by means of making the types precise or adding
>> explicit casts. There's quite a few changes in the ByteBuffers benchmarks,
>> but the real
On Wed, 11 May 2022 16:00:42 GMT, Claes Redestad wrote:
> Thanks for reviewing. I'll let the GHA tests complete and integrate this
> tomorrow if all is clear.
I don't think GHA builds any microbenchmarks (because JMH is not enabled
there), so there is no point to wait for those.
-
Current `sun/security/provider/SHA2` implementation is written with lots of
small method invocations on the fastpath in `implCompress0`. Normally it does
not matter much, because compilers are able to inline through it, and then some
compilers even intrinsify the entire `implCompress0`.
But it
On Tue, 17 Nov 2020 21:46:38 GMT, Weijun Wang wrote:
> This is a micro benchmark for various algorithm settings of PKCS keystores.
> Strong for new algorithms and weak for old ones. Different iteration counts
> are tried. The result should show that the current setting (strong1) is
> more
On Wed, 18 Nov 2020 14:49:54 GMT, Weijun Wang wrote:
>> test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 65:
>>
>>> 63: }
>>> 64:
>>> 65: static {
>>
>> Move these to
>>
>> @Setup
>> public void setup() throws Exception {
>> ...
>> }
>>
>> This would save you a
On Wed, 18 Nov 2020 18:53:21 GMT, Weijun Wang wrote:
>> This is a micro benchmark for various algorithm settings of PKCS keystores.
>> Strong for new algorithms and weak for old ones. Different iteration counts
>> are tried. The result should show that the current setting (strong1) is
>> m
On Fri, 20 Nov 2020 00:14:55 GMT, Valerie Peng wrote:
>> Current `sun/security/provider/SHA2` implementation is written with lots of
>> small method invocations on the fastpath in `implCompress0`. Normally it
>> does not matter much, because compilers are able to inline through it, and
>> then
On Fri, 20 Nov 2020 20:05:19 GMT, Valerie Peng wrote:
>> Thank you, @valeriepeng. I am not sure what is the review policy for this
>> code, should I wait for another reviewer?
>
> One reviewer is good enough. You can go ahead and integrate. Thanks~
Got it, thanks!
-
PR: https://gi
On Wed, 18 Nov 2020 08:29:49 GMT, Aleksey Shipilev wrote:
> Current `sun/security/provider/SHA2` implementation is written with lots of
> small method invocations on the fastpath in `implCompress0`. Normally it does
> not matter much, because compilers are able to inline through it,
On Fri, 4 Dec 2020 22:58:07 GMT, Xue-Lei Andrew Fan wrote:
> In the SunJSSE provider implementation, there are a few class fields are not
> used other than the constructors. Those fields could be removed and replaced
> with local variables.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-825
On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart wrote:
> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
Looks good, but can we not do the behavioral change in
`ensureClassIn
On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote:
>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one
SonarCloud reports:
Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the
"Object.equals(Object obj)" method.
} else if (!src.isDirect() && !dst.isDirect()) {
if (!src.isReadOnly()) {
// If using the heap, check underlying byte[] addre
On Thu, 11 Mar 2021 17:36:00 GMT, Anthony Scarpino
wrote:
>> SonarCloud reports:
>> Use "Arrays.equals(array1, array2)" or the "==" operator instead of using
>> the "Object.equals(Object obj)" method.
>>
>> } else if (!src.isDirect() && !dst.isDirect()) {
>> if (!src.isRe
On Thu, 11 Mar 2021 18:19:41 GMT, Anthony Scarpino
wrote:
>> SonarCloud reports:
>> Use "Arrays.equals(array1, array2)" or the "==" operator instead of using
>> the "Object.equals(Object obj)" method.
>>
>> } else if (!src.isDirect() && !dst.isDirect()) {
>> if (!src.isRe
On Thu, 11 Mar 2021 11:22:40 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> Use "Arrays.equals(array1, array2)" or the "==" operator instead of using
> the "Object.equals(Object obj)" method.
>
> } else if (!src.isDirect() &&
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 = 0; i < nameStrings.length; i++) {
result[i] = new byte[nameStrin
{
> result[i] = new byte[nameStrings[i].length()]; // <-- here
> result[i] = nameStrings[i].getBytes();
> }
> return result;
> }
>
> `getBytes()` returns the `byte[]` array, there is no need to allocate the
> array before
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][];
>
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base
On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the `jav
On Thu, 8 Apr 2021 17:02:20 GMT, Sean Mullan wrote:
>> 8264681: Use the blessed modifier order in java.security
>
> src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java
> line 390:
>
>> 388: }
>> 389:
>> 390: public abstract PSSParameterSpec g
On Sat, 3 Apr 2021 22:09:55 GMT, Alex Blewitt
wrote:
> 8264681: Use the blessed modifier order in java.security
I think some review comments from Sean were left unaddressed...
-
Changes requested by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3338
On Mon, 12 Apr 2021 09:32:13 GMT, Alex Blewitt
wrote:
>> 8264681: Use the blessed modifier order in java.security
>
> Alex Blewitt has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removed upstream licensed code from commit
I think all conv
SonarCloud reports:
"Remove or correct this useless self-assignment."
if (cipherAlgo.equals("AES")) {
this.keysize = keysize; // < here
switch (keysize) {
case 128:
cipherAlgo_OID = aes128CBC_OID;
Seems to be here since initial add
SonarCloud again complains about GaloisCounterMode.overlapDetection, in the
similar way JDK-8263436 did. I think JDK-827 accidentally reintroduced the
old code.
The tangential question if JDK-827 reverted anything else.
Additional testing:
- [x] `jdk_security` passes
-
Co
On Wed, 23 Jun 2021 07:38:37 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> "Remove or correct this useless self-assignment."
>
>
> if (cipherAlgo.equals("AES")) {
> this.keysize = keysize; // < here
>
On Wed, 23 Jun 2021 08:10:40 GMT, Aleksey Shipilev wrote:
> SonarCloud again complains about GaloisCounterMode.overlapDetection, in the
> similar way JDK-8263436 did. I think JDK-827 accidentally reintroduced
> the old code.
>
> The tangential question if JDK-827 re
On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote:
> This CA had no code signing certificates issued so it is safe to remove it
> from cacerts truststore.
Looks like a clean removal to me. Approving so this can be backported to JDK
Updates that would be after the cert expiry date.
On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
>
> Given the nature of the code in `ReferralsCache`, I haven't been able to add
> a new jtreg test cas
On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari wrote:
> ### Motivation
>
> When profiling an application that uses JWT token authentication, it was
> noticed that a high number of `javax.crypto.BadPaddingException`s were
> created. When investigating the code in RSAPadding, one can see that
>
SonarCloud reports:
A "Map" cannot contain a "String" in a "ServiceKey" type.
// clean up old alias if present
Service prevAliasService = legacyMap.get(aliasAlg);
Should be `aliasKey`, like other accesses to `legacyMap`. This code is
introduced by [JDK-8276660](https://bugs.openjdk.
cesses to `legacyMap`. This code is
> introduced by
> [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it
> affects JDK 18.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `jdk_security`
Aleksey Shipilev has updated the pull request with a new target b
On Thu, 23 Dec 2021 21:06:51 GMT, Valerie Peng wrote:
>> Hmm, this "ADD" case should be covered by existing regression tests. I will
>> take a look. Thanks.
>
> Hmm, existing test does add an alias, the legacyMap.get() would returns null
> upon 'aliasAlg' (type: String). To test this particular
On Thu, 23 Dec 2021 21:06:51 GMT, Valerie Peng wrote:
>> Hmm, this "ADD" case should be covered by existing regression tests. I will
>> take a look. Thanks.
>
> Hmm, existing test does add an alias, the legacyMap.get() would returns null
> upon 'aliasAlg' (type: String). To test this particular
cesses to `legacyMap`. This code is
> introduced by
> [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it
> affects JDK 18.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `jdk_security`
Aleksey Shipilev has updated the pull request with a new target b
On Mon, 3 Jan 2022 22:36:32 GMT, Valerie Peng wrote:
>> The test update checks that the alias maps to the right algorithm. However,
>> the particular code change covered by this fix is for removing the alias
>> from the previous algorithm which is not triggered by the test change. Alias
>> is
On Thu, 23 Dec 2021 13:33:26 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> A "Map" cannot contain a "String" in a "ServiceKey"
> type.
>
>
> // clean up old alias if present
> Service prevAliasService = legacyMap.get(
On Tue, 4 Jan 2022 06:59:58 GMT, Aleksey Shipilev wrote:
>> SonarCloud reports:
>> A "Map" cannot contain a "String" in a "ServiceKey"
>> type.
>>
>>
>> // clean up old alias if present
>> Service prevAlias
52 matches
Mail list logo
