if ((nextByte == DerValue.tag_SequenceOf)
&& (! ((nextByte & 0x0c0) == 0x080))) {
...
...
}
If `nextByte` is `DerValue.tag_SequenceOf`, exactly `0x30`, then the test after
`&&` should always be true.
-
Commit messages:
- 8313226: Redundant condition test in X509CRLI
On Tue, 25 Jul 2023 06:27:25 GMT, John Jiang wrote:
> Some java/security classes apply the below coding style,
>
> Set set = ...;
> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>
> It may be unnecessary to wrap that `set` with HashSet before creating
> `unmodifiableSe
On Wed, 26 Jul 2023 16:52:20 GMT, Sean Mullan wrote:
> The latter part is true (prevented from subsequent modification) but, unless
> I am mistaken, the former (making a clone/copy) is not. For example, before
> your change, this assert would pass:
>
> ```
> Map m = Collections.unmodifiableMap
On Wed, 26 Jul 2023 06:11:56 GMT, Xue-Lei Andrew Fan wrote:
>> Some java/security classes apply the below coding style,
>>
>> Set set = ...;
>> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>>
>> It may be unnecessary to wrap that `set` with HashSet before creating
>>
On Wed, 26 Jul 2023 16:03:31 GMT, John Jiang wrote:
> > it says "It is cloned to prevent subsequent modification."
> > Now, if the set passed in is unmodifiable, that is no longer true.
>
> My understanding: The parameter `protectionParams` is cloned as
> `this.protectionParams`, and `this.prot
On Wed, 26 Jul 2023 09:28:46 GMT, John Jiang wrote:
>> Some java/security classes apply the below coding style,
>>
>> Set set = ...;
>> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>>
>> It may be unnecessary to wrap that `set` with HashSet before creating
>> `unmodif
On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with th
On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with th
On Mon, 24 Jul 2023 15:13:42 GMT, Rajan Halade wrote:
> This is an update to test certificates issued by Amazon root CA. The new EE
> certificates have CRLDP so I have enabled CRL check on those. This test is
> updated to cover the failure while we wait for
> [JDK-8308592](https://bugs.openjdk
On Wed, 26 Jul 2023 15:58:15 GMT, Vyom Tewari wrote:
>>> please reformat line 173
>>
>> Why?
>
> "buf = (char*)malloc(len*sizeof(char));" --> "buf = (char*)malloc(len *
> sizeof(char));"
> "buf = (char*)malloc(len_sizeof(char));" --> "buf = (char_)malloc(len *
> sizeof(char));"
Both sides of
On Wed, 26 Jul 2023 14:41:16 GMT, Sean Mullan wrote:
> it says "It is cloned to prevent subsequent modification."
> Now, if the set passed in is unmodifiable, that is no longer true.
My understanding:
The parameter `protectionParams` is cloned as `this.protectionParams`,
and `this.protectionPar
On Wed, 26 Jul 2023 15:49:38 GMT, Brian Burkhalter wrote:
>> src/java.base/share/native/libjava/io_util.c line 173:
>>
>>> 171: if (len > MAX_MALLOC_SIZE)
>>> 172: len = MAX_MALLOC_SIZE;
>>> 173: buf = (char*)malloc(len*sizeof(char));
>>
>> please reformat line 173
>
On Wed, 26 Jul 2023 05:31:57 GMT, Vyom Tewari wrote:
> please reformat line 173
Why?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275174632
On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman wrote:
> I think the main issue with this version is that it changes behavior of the
> read methods to work like "read fully", I don't think we should do that.
To me it looks more like `readNBytes`.
-
PR Comment: https://git.openjdk.o
On Mon, 24 Jul 2023 15:13:42 GMT, Rajan Halade wrote:
> This is an update to test certificates issued by Amazon root CA. The new EE
> certificates have CRLDP so I have enabled CRL check on those. This test is
> updated to cover the failure while we wait for
> [JDK-8308592](https://bugs.openjdk
On Wed, 26 Jul 2023 04:02:04 GMT, John Jiang wrote:
> DerValue::toString may be better to output the hex view of the byte array
> variable `buffer`.
This pull request has now been integrated.
Changeset: 830413f1
Author:John Jiang
URL:
https://git.openjdk.org/jdk/commit/830413f19a6d
On Wed, 26 Jul 2023 05:26:52 GMT, Vyom Tewari wrote:
>> Brian Burkhalter has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - 6478546: Decrease malloc limit to 1.5 MB
>> - 6478546: Minor refactoring
>> - 6478546: Prevent short read
>
>
On Wed, 26 Jul 2023 09:28:46 GMT, John Jiang wrote:
>> Some java/security classes apply the below coding style,
>>
>> Set set = ...;
>> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>>
>> It may be unnecessary to wrap that `set` with HashSet before creating
>> `unmodif
On Wed, 26 Jul 2023 13:49:49 GMT, Sean Mullan wrote:
>> DerValue::toString may be better to output the hex view of the byte array
>> variable `buffer`.
>
> Please change the title of the bug to be "DerValue::toString should output a
> hex view of the values in byte array".
>
> Otherwise, LGTM.
On Wed, 26 Jul 2023 04:02:04 GMT, John Jiang wrote:
> DerValue::toString may be better to output the hex view of the byte array
> variable `buffer`.
Please change the title of the bug to be "DerValue::toString should output a
hex view of the values in byte array".
Otherwise, LGTM.
--
On Wed, 26 Jul 2023 06:11:56 GMT, Xue-Lei Andrew Fan wrote:
>> Some java/security classes apply the below coding style,
>>
>> Set set = ...;
>> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>>
>> It may be unnecessary to wrap that `set` with HashSet before creating
>>
On Wed, 26 Jul 2023 00:00:33 GMT, Brian Burkhalter wrote:
> There was no dropping of the file system cache. I would think this would have
> more of an effect on measuring the throughput of writing than reading.
In that case, I assume the benchmarks are just reading from the file system
cache s
On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with th
> Some java/security classes apply the below coding style,
>
> Set set = ...;
> Set unmodifiableSet = Collections.unmodifiableSet(new HashSet<>(set));
>
> It may be unnecessary to wrap that `set` with HashSet before creating
> `unmodifiableSet`.
> Some usages on `Collections.unmodifiableList` an
24 matches
Mail list logo