Re: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v3]
On Mon, 23 May 2022 21:44:39 GMT, Valerie Peng wrote: >> Need to update the 3 header files due to expiring business approval for 3rd >> party. >> >> The header files contain tabs which jcheck disallows, so I have to replace >> them with spaces. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Added a link for COPYING as on the pcsc-lite website LGTM. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8853
Re: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v3]
> Need to update the 3 header files due to expiring business approval for 3rd > party. > > The header files contain tabs which jcheck disallows, so I have to replace > them with spaces. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added a link for COPYING as on the pcsc-lite website - Changes: - all: https://git.openjdk.java.net/jdk/pull/8853/files - new: https://git.openjdk.java.net/jdk/pull/8853/files/42c9df2a..32b75b6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8853=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8853=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853
Re: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v2]
> Need to update the 3 header files due to expiring business approval for 3rd > party. > > The header files contain tabs which jcheck disallows, so I have to replace > them with spaces. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Fix indentation - Changes: - all: https://git.openjdk.java.net/jdk/pull/8853/files - new: https://git.openjdk.java.net/jdk/pull/8853/files/8344ddb5..42c9df2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8853=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8853=00-01 Stats: 192 lines in 3 files changed: 0 ins; 1 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853
RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5
Need to update the 3 header files due to expiring business approval for 3rd party. The header files contain tabs which jcheck disallows, so I have to replace them with spaces. Thanks, Valerie - Commit messages: - Replaced tab with spaces in order to pass jcheck. - 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 Changes: https://git.openjdk.java.net/jdk/pull/8853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8853=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286211 Stats: 221 lines in 4 files changed: 2 ins; 14 del; 205 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853
Re: RFR: 8284209: Replace remaining usages of 'a the' in source code [v2]
> Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge master - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'an? an?' in source code - 8284209: Replace remaining usages of 'a the' in source code - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb - Changes: https://git.openjdk.java.net/jdk/pull/8771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8771=01 Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771
Integrated: 8287109: Distrust.java failed with CertificateExpiredException
On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote: > Incorporated patch from my @seanjmullan and removed expired root chains. This pull request has now been integrated. Changeset: 5b7d066c Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/5b7d066ca5cb68e07a704d3ce13283761c1cf3ad Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod 8287109: Distrust.java failed with CertificateExpiredException Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/8856
RFR: 8287109: Distrust.java failed with CertificateExpiredException
Incorporated patch from my @seanjmullan and removed expired root chains. - Commit messages: - Reformat code - Update ProblemList - 8287109: Distrust.java failed with CertificateExpiredException Changes: https://git.openjdk.java.net/jdk/pull/8856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8856=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287109 Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8856/head:pull/8856 PR: https://git.openjdk.java.net/jdk/pull/8856
Re: RFR: 8287109: Distrust.java failed with CertificateExpiredException
On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote:
> Incorporated patch from my @seanjmullan and removed expired root chains.
LGTM although someone else should probably have a look over this since I
contributed the fix.
test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java line 183:
> 181: } catch (CertificateException ce) {
> 182: // expired TLS certificates should not be treated as failure
> 183: if(expired(ce)) {
add space after "if".
-
Marked as reviewed by mullan (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8856
Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v3]
> Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8768=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8768=01-02 Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration LGTM - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs wrote: >> You are right. The old way maps the null string to true, and the new way >> maps it to false. I did not notice that. At this point, I see no value in >> making the "true".equals and "false".equals changes. Too much can break. >> I'll reverse these changes. > > This change still needs to be reversed. The change has been reversed. We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too. - PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
> JDK-6725221 Standardize obtaining boolean properties with defaults Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Alan and Jamil comments - Merge - reverse true.equals and false.equals changes - Merge - Merge - first iteration - Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8559=01 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults
On Tue, 10 May 2022 19:24:24 GMT, Mark Powers wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
>>
>>> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>>> 776: printStackWhenAccessFails = GetBooleanAction.
>>> 777:
>>> privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
>>
>> Running with `-Dsun.reflect.debugModuleAccessChecks` should set
>> printStackWhenAccessFails to true, not false.
>
> You are right. The old way maps the null string to true, and the new way maps
> it to false. I did not notice that. At this point, I see no value in making
> the "true".equals and "false".equals changes. Too much can break. I'll
> reverse these changes.
This change still needs to be reversed.
-
PR: https://git.openjdk.java.net/jdk/pull/8559
Integrated: 8286908: ECDSA signature should not return parameters
On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, > remove the remembered `sigParams` field. One behavior change is that after > calling `setParameter()`, one can call `init()` again with a key using > different parameters. I think this should be allowed since we are reusing the > signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still > having parameters after the signature algorithm object identifier. See > https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. This pull request has now been integrated. Changeset: 8040aa00 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/8040aa0073e7ea22b2fdff5bddff10c244e116ef Stats: 109 lines in 4 files changed: 60 ins; 36 del; 13 mod 8286908: ECDSA signature should not return parameters Reviewed-by: ascarpino, hchao, valeriep - PR: https://git.openjdk.java.net/jdk/pull/8758
Integrated: 8286715: Generalize MemorySegment::ofBuffer
On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to > pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can > obtain the address of any direct buffer instance, using the > `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a > buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct > buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct > `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the > `Buffer` API. As such it would not be possible to map many memory segments > into an `IntBuffer`; in fact, the only segment we could safely map into an > `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it > doesn't seem worth adding a lot of API surface (in terms of additional > overloads) for such a corner case. This pull request has now been integrated. Changeset: 89a1d055 Author:Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/89a1d055d93ad57bcec7c1accb3f53b4c30f594d Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod 8286715: Generalize MemorySegment::ofBuffer Reviewed-by: jvernee - PR: https://git.openjdk.java.net/jdk/pull/8701
