On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter wrote:
> Please review this small change to handle `EINTR` from `close()` in
> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
> file.
On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 16 -> JDK 17
This pull request has now been integrated.
Changeset: 133bcb09
Author:Jesper Wilhelmsson
URL: https://git.openjdk.java.net/jdk/commit/133bcb09
Stats: 296 lines in 31 files changed: 200
On Wed, 20 Jan 2021 17:27:43 GMT, Mahendra Chhipa
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8183372
Can this be done all in `EnclosingClassTest.java`, without a new
`RunEnclosingClassTest.java`?
Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may
just need
Forwardport JDK 16 -> JDK 17
-
Commit messages:
- Merge
- 8259757: add a regression test for 8259353 and 8259601
- 8259732: JDK 16 L10n resource file update - msg drop 10
The webrevs contain the adjustments done while merging with regards to each
parent branch:
- master:
On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter wrote:
> Please review this small change to handle `EINTR` from `close()` in
> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
> file.
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote:
> Change `MethodHandles.byteArrayViewVarHandle` to throw
> `ArrayIndexOutOfBoundsException` rather than the more generic
> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
> risk for subtle behavioral mismatch
On Wed, 20 Jan 2021 12:21:21 GMT, Claes Redestad wrote:
> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is
> erroneously using a shared CharsetDecoder when the fast-path fails. It needs
> to go via creating a new String like before JDK-8243469
>
> This should
On Tue, 12 Jan 2021 16:58:45 GMT, Jorn Vernee wrote:
> Hi,
>
> This small patch fixes the NPE in the following case:
>
> MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class,
> int.class, int.class));
> MethodHandles.permuteArguments(mh,
Please review this small change to handle `EINTR` from `close()` in
`fileDescriptorClose()`. The function `handleGetLength()` is also changed to
handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.
-
Commit messages:
- 8259943: FileDescriptor.close0 does
On Wed, 20 Jan 2021 13:03:04 GMT, Claes Redestad wrote:
>> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder
>> is erroneously using a shared CharsetDecoder when the fast-path fails. It
>> needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469
>>
>> This
On Wed, 20 Jan 2021 09:33:43 GMT, Jie Fu wrote:
>> That change may cause performance issues. I would recommend leaving as is
>> for now even through the error message is not great. Bounds checking is
>> quite sensitive and WIP. Notice that we also have an option to call
>>
On Wed, 20 Jan 2021 18:47:18 GMT, Claes Redestad wrote:
>> Change `MethodHandles.byteArrayViewVarHandle` to throw
>> `ArrayIndexOutOfBoundsException` rather than the more generic
>> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
>> risk for subtle behavioral
> Change `MethodHandles.byteArrayViewVarHandle` to throw
> `ArrayIndexOutOfBoundsException` rather than the more generic
> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
> risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to
> VHs.
>
>
Add explicit range check to `MethodHandles.collectArgumentsCheck`.
Added test case that exercises all cases.
This is a behavioral change, from throwing an unspecified exception to throwing
an IllegalArgumentException, as specified.
No spec change needed, as the IllegalArgumentException is
https://bugs.openjdk.java.net/browse/JDK-8183372
-
Commit messages:
- JDK-8183372 : Refactor java/lang/Class shell tests to java
Changes: https://git.openjdk.java.net/jdk/pull/2170/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2170=00
Issue:
On Wed, 20 Jan 2021 15:34:24 GMT, Alexey Bakhtin wrote:
> New ChannelBinding Data will be recreated for every TLS connection and
> provided to SASL Client in the new environment properties set (cloned from
> the original).
> LdapSasl.java lines 133 - 136:
>
> ```
>
On Wed, 20 Jan 2021 15:08:56 GMT, Aleksei Efimov wrote:
>> That look reasonable to me. But what would happen if at some point after
>> performing some LDAP operations, you called StartTLSResponse::close and then
>> after some more time you tried to again create a StartTLSRequest on the same
>
> I suspect some refactoring is needed as some of this code in ParseUtil
> is not general purpose and should probably move to the jar URL handler.
> A discussion for net-dev when there is a patch to discuss.
>
https://github.com/openjdk/jdk/pull/2167
This moves the utility methods into Handler
On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad wrote:
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
> has fast-paths for common encoding) and avoiding a `toCharArray` call on the
> input by refactoring the `normalizeNativePath` code to operate on `String`.
>
On Wed, 20 Jan 2021 13:33:30 GMT, Aleksey Shipilev wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:
>
>> 101:
On Wed, 20 Jan 2021 14:41:26 GMT, Daniel Fuchs wrote:
>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
>> Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> That look reasonable to me. But what would happen if at some point after
On Wed, 20 Jan 2021 15:08:22 GMT, Claes Redestad wrote:
>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
>> has fast-paths for common encoding) and avoiding a `toCharArray` call on the
>> input by refactoring the `normalizeNativePath` code to operate on `String`.
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
> has fast-paths for common encoding) and avoiding a `toCharArray` call on the
> input by refactoring the `normalizeNativePath` code to operate on `String`.
> This might have a cost on files on Mac that need
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote:
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
That look reasonable to me. But what would happen if at some point after
On Wed, 20 Jan 2021 14:01:45 GMT, Sean Mullan wrote:
>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
>> Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Marked as reviewed by mullan (Reviewer).
Sean, Thank you for review
On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad wrote:
>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
>> has fast-paths for common encoding) and avoiding a `toCharArray` call on the
>> input by refactoring the `normalizeNativePath` code to operate on `String`.
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote:
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Marked as reviewed by mullan (Reviewer).
-
PR:
On Wed, 20 Jan 2021 07:21:22 GMT, Alexey Bakhtin wrote:
> Unfortunately, I can not find any LDAP StartTLS Extended Operation regression
> tests. security/infra area contains RevocationChecker tests. They can not be
> used for this scenario.
Ok, please add a noreg-hard label to the bug.
On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote:
> This is the changes for JDK 16 msg drop 10.
This pull request has now been integrated.
Changeset: 01205109
Author:Leo Jiang
URL: https://git.openjdk.java.net/jdk16/commit/01205109
Stats: 215 lines in 30 files changed: 118 ins;
On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
>
>> 44:
> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is
> erroneously using a shared CharsetDecoder when the fast-path fails. It needs
> to go via JLA.newStringUTF8NoRepl like before JDK-8243469
>
> This should resolve a rare issue when doing a lot of jar scanning in
On Wed, 20 Jan 2021 12:52:30 GMT, eirbjo
wrote:
>> Claes Redestad has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Reuse normalizedHash(String)
>> - copyright
>> - Don't use No Replace variant to calculate hash, more fixes
>
>
On Wed, 20 Jan 2021 12:21:21 GMT, Claes Redestad wrote:
> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is
> erroneously using a shared CharsetDecoder when the fast-path fails. It needs
> to go via JLA.newStringUTF8NoRepl like before JDK-8243469
>
> This should
This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is
erroneously using a shared CharsetDecoder when the fast-path fails. It needs to
go via JLA.newStringUTF8NoRepl like before JDK-8243469
This should resolve a rare issue when doing a lot of jar scanning in parallel
on
On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote:
> Change `MethodHandles.byteArrayViewVarHandle` to throw
> `ArrayIndexOutOfBoundsException` rather than the more generic
> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
> risk for subtle behavioral mismatch
On 2021-01-20 13:02, Alan Bateman wrote:
On 20/01/2021 11:57, Claes Redestad wrote:
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a
On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo
wrote:
> ZipFile.Source.initCEN verifies that entry names are encoding into bytes
> valid in the entry's encoding. It does so by calling encoding-specific
> checking methods, so it also needs to determine which check method to call
> for each entry.
>
On 20/01/2021 11:57, Claes Redestad wrote:
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a concept known to ParseUtil. Or move the util
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a concept known to ParseUtil. Or move the util methods
to the Handler, since it's the only
> Hi all,
>
> For this reproducer:
>
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
>
> public class Test {
> static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128;
> static byte[] a = new byte[8];
> static byte[] b = new byte[8];
>
On Tue, 19 Jan 2021 21:40:24 GMT, Paul Sandoz wrote:
>> Hi all,
>>
>> For this reproducer:
>>
>> import jdk.incubator.vector.ByteVector;
>> import jdk.incubator.vector.VectorSpecies;
>>
>> public class Test {
>> static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128;
>>
42 matches
Mail list logo
