On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote:
> Correct the result string coder of a string encoded using a CharsetDecoder
> with multi-byte encoded input.
> Added tests for UTF16 strings and a regression test.
test/jdk/java/nio/file/Files/ReadWriteString.java line 322:
> 320:
On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi wrote:
> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will
> thus fall back to slower default method of `List.sort()` instead of sorting a
> range of the array in-place in its backing root `ArrayList`.
>
> This
On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi wrote:
> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will
> thus fall back to slower default method of `List.sort()` instead of sorting a
> range of the array in-place in its backing root `ArrayList`.
>
> This
Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will
thus fall back to slower default method of `List.sort()` instead of sorting a
range of the array in-place in its backing root `ArrayList`.
This doesn't change observable behavior, so haven't added tests, and `tier1`
On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
Correct the result string coder of a string encoded using a CharsetDecoder with
multi-byte encoded input.
Added tests for UTF16 strings and a regression test.
-
Commit messages:
- 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
Changes:
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
>
On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: Properties files is essentially source code. It should have
>> the same whitespace checks as all other source code, so we don't get
>> spurious
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
>
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
>
On Tue, 2 Jan 2024 14:37:16 GMT, Pavel Rappo wrote:
>> This PR adds an internal method to calculate hash code from the provided
>> integer array, offset and length into that array, and the initial hash code
>> value.
>>
>> Current options for calculating a hash code for int[] are inflexible.
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
>
Ran the test on AmazonLinux 2 which has multiple binaries from coreutils
package and no coreutils executable as well as AmazonLinux 2023 that uses
`--enable-single-binary`
-
Commit messages:
- TEST_BUG: java/lang/ProcessHandle/InfoTest.java#test3 fails on systems with
coreutils
Hi,
Could the problem have occurred because the ForkJoinPool got an OOME when it
tried to allocate a ForkJoinWorkerThread?
To check for that, if you're using the commonPool(), you might be able to add a
custom ForkJoinWorkerThreadFactory via passing in
On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote:
> On some Windows machines we see sometimes OOM errors because of high resource
> (memory/swap) consumption. This is especially seen when the jtreg runs have
> higher concurrency. A solution is to put the java/lang/StringBuilder tests
On Fri, 9 Feb 2024 12:31:27 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
>> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
>> tested.
>>
>> The disk space requirement of this test is known to cause
On Fri, 9 Feb 2024 10:41:18 GMT, Eirik Bjørsnøs wrote:
>> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 112:
>>
>>> 110: ZipEntry e1 = new ZipEntry("first");
>>> 111: // Make room for an 8-byte ZIP64 extra field
>>> 112:
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesystem ID field in statvfs
On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: Properties files is essentially source code. It should have
>> the same whitespace checks as all other source code, so we don't get
>> spurious trailing
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
This pull request has now been integrated.
Changeset:
On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesystem ID field in statvfs
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
24 matches
Mail list logo
