On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
On Mon, 26 Feb 2024 06:43:43 GMT, Joe Darcy wrote:
> To improve the "fingerprinting" coverage of the StrictMath tests, I've added
> test cases where the worst-case of a non-FDLIBM library is larger than the
> FDLIBM worst-case. Assuming reasonable methodology of the paper, the output
> of the
On Sat, 24 Feb 2024 20:31:13 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> details the inputs with generate the worst-case
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Sun, 25 Feb 2024 19:05:58 GMT, Lance Andersen wrote:
> I would suggest "ZIP file" based on the PKWare APPNOTE.TXT,
I think using this case would be good.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1502076153
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Sun, 25 Feb 2024 15:26:35 GMT, Alan Bateman wrote:
> (In passing, the casing of "zip file" is very inconsistent in the javadoc,
> it's "ZIP file" in some places, "zip file" in others, the change here uses
> "Zip file").
Thank you for pointing out the discrepancy above.
Let's decide on
On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen wrote:
> In the current version, FMT."v =%d{1}" will call the
> StringConcatHelper.prepend(long/byte[]/long) method, which should behave the
> same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int),
> should not convert int to long
On Sun, 25 Feb 2024 14:17:05 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Thu, 22 Feb 2024 14:06:25 GMT, Eirik Bjørsnøs wrote:
> Alan,
>
> Finding a good way to express this while being correct and succinct was
> surprisingly hard. What I have now is probably far from perfect, but at least
> something to serve as a starting point for review:
The `@depreacted`
On Sun, 25 Feb 2024 14:17:05 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Sun, 25 Feb 2024 12:20:36 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updates based on 1st round of feedback
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 524:
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change, `ZipFile::getComment` will now return `null` if an
> invalid UTF-8 byte
On Sun, 25 Feb 2024 12:16:14 GMT, Jaikiran Pai wrote:
> Hello Lance, the changes look fine to me. `ZipFile.java` file will need a
> copyright year update.
Thank you Jai, updated
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 189:
>
>> 187: try (ZipFile zf
On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote:
> Fix the @param name
This pull request has now been integrated.
Changeset: 1799ffea
Author:Korov
Committer: Jaikiran Pai
URL:
https://git.openjdk.org/jdk/commit/1799ffeaa9baa7d703c7acc8d8738211694f946e
Stats: 1 line in 1 file
On Sun, 25 Feb 2024 11:37:05 GMT, Korov wrote:
>> Fix the @param name
>
> Korov has updated the pull request incrementally with one additional commit
> since the last revision:
>
> array -> collection
Thank you for the update. The change is trivial and looks good to me.
-
On Sun, 25 Feb 2024 11:37:05 GMT, Korov wrote:
>> Fix the @param name
>
> Korov has updated the pull request incrementally with one additional commit
> since the last revision:
>
> array -> collection
src/java.base/share/classes/java/util/ImmutableCollections.java line 164:
> 162: *
>
> Fix the @param name
Korov has updated the pull request incrementally with one additional commit
since the last revision:
array -> collection
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17996/files
- new:
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote:
> Fix the @param name
src/java.base/share/classes/java/util/ImmutableCollections.java line 164:
> 162: *
> 163: * @param the List's element type
> 164: * @param coll the input array
Hello @Korov, while at it, can you also change
On Sun, 25 Feb 2024 08:27:41 GMT, Jim Laskey wrote:
>> Fix the @param name
>
> Marked as reviewed by jlaskey (Reviewer).
@JimLaskey Hi, this commit has passed all checks, I also executed the
`/integrate` command. I need your help to execute the next command `/sponsor`.
If there are other
On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote:
> Fix the @param name
Marked as reviewed by jlaskey (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17996#pullrequestreview-1899627681
Fix the @param name
-
Commit messages:
- 8310351: Typo in ImmutableCollections
Changes: https://git.openjdk.org/jdk/pull/17996/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17996=00
Issue: https://bugs.openjdk.org/browse/JDK-8310351
Stats: 1 line in 1 file changed: 0
29 matches
Mail list logo
