Re: RFR: 8331907: BigInteger and BigDecimal should use optimized division [v4]

2024-05-13 Thread Brian Burkhalter
On Fri, 10 May 2024 16:16:18 GMT, Daniel JeliƄski wrote: >> Replace the custom unsigned divide / remainder functions with the >> compiler-optimized Long.divideUnsigned / remainderUnsigned. >> >> No new tests. Existing tier1-3 tests continue to pass. >> >> I added a new set of divide

Re: RFR: 8332029: Provide access to initial value of stderr via JavaLangAccess

2024-05-10 Thread Brian Burkhalter
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote: > In preparation for JEP 471 and JEP 472, provide access to the initial value > of System.err from JavaLangAccess. The initial value of System.in is already > exposed to code in java.base with this shared secret. +1 - Marked

Re: RFR: 8332064: Implementation of Structured Concurrency (Third Preview)

2024-05-10 Thread Brian Burkhalter
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote: > There aren't any API or implementations changes in third preview but the JEP > number/title needs to be bumped for the javadoc page. Marked as reviewed by bpb (Reviewer). - PR Review:

Re: Need for a sponsor for JDK-8313674

2024-05-03 Thread Brian Burkhalter
Hello, This is the PR [1]. This is the sequence that should be followed: 1. Align the name title of the PR with the issue. (you) 2. Continue the conversation until at least one Reviewer approves it. (one or more of us) 3. Comment with /integrate command. (you) 4. Comment with /sponsor command.

Integrated: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

2024-04-29 Thread Brian Burkhalter
On Mon, 22 Apr 2024 19:07:04 GMT, Brian Burkhalter wrote: > Prevent blocking due to a carrier thread not being released when > `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. This pull request has now been integrated. Changeset: 819f3d6f Author: Brian Burkhalte

Re: RFR: 8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute

2024-04-25 Thread Brian Burkhalter
On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy wrote: > Remove unnecessary setting of variable y, found by an IDE inspection noted in > the bug report. Marked as reviewed by bpb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18963#pullrequestreview-2023708504

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v4]

2024-04-24 Thread Brian Burkhalter
On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter wrote: >> Prevent blocking due to a carrier thread not being released when >> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. > > Brian Burkhalter has updated the pull request with a new target base

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v4]

2024-04-24 Thread Brian Burkhalter
> Prevent blocking due to a carrier thread not being released when > `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes b

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-24 Thread Brian Burkhalter
On Wed, 24 Apr 2024 14:54:34 GMT, Viktor Klang wrote: >> Currently we have >> >> public void writeTo(OutputStream out) throws IOException { >> if (Thread.currentThread().isVirtual()) { >> out.write(toByteArray()); >> } else synchronized (this) { >>

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-24 Thread Brian Burkhalter
On Wed, 24 Apr 2024 07:08:20 GMT, Alan Bateman wrote: >> So do we think it better not to invoke `toByteArray` here? > > Using a subclass to count the number of invocations of toByteArray seems a > bit strange but in general it is more robust to not rely on a method that may > be overridden by

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-23 Thread Brian Burkhalter
On Tue, 23 Apr 2024 06:20:47 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Correct ID in test @bug tag > > test/jdk/java/io/ByteArrayOutputStream/Write

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v3]

2024-04-23 Thread Brian Burkhalter
> Prevent blocking due to a carrier thread not being released when > `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8330748: Add vthread1.join() i

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-23 Thread Brian Burkhalter
On Tue, 23 Apr 2024 17:35:42 GMT, Jason Mehrens wrote: >> A good question. The buf/count fields are protected so the subclass has >> direct access to the bytes. So while it could Arrays.copy the bytes, it >> doesn't help with a buggy subclass that is changing bytes without >> synchronization.

Re: RFR: 8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O [v2]

2024-04-23 Thread Brian Burkhalter
On Tue, 23 Apr 2024 08:09:20 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/FileInputStream.java line 211: >> >>> 209: * @param name the name of the file >>> 210: */ >>> 211: private void open(String name) throws FileNotFoundException { >> >> If method such as

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-22 Thread Brian Burkhalter
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote: >> Prevent blocking due to a carrier thread not being released when >> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. > > Brian Burkhalter has updated the pull request incrementally with one > ad

Re: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier [v2]

2024-04-22 Thread Brian Burkhalter
> Prevent blocking due to a carrier thread not being released when > `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: Correct ID in test @b

RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

2024-04-22 Thread Brian Burkhalter
Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread. - Commit messages: - 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier Changes: https://git.openjdk.org/jdk/pull/18901/files Webrev:

Re: RFR: 8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O [v2]

2024-04-22 Thread Brian Burkhalter
On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman wrote: >> This change drops the adjustments to the virtual thread scheduler's target >> parallelism when virtual threads do file operations on files that are opened >> for buffered I/O. These operations are usually just too short to have any >>

Re: RFR: 8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O

2024-04-09 Thread Brian Burkhalter
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote: > This change drops the adjustments to the virtual thread scheduler's target > parallelism when virtual threads do file operations on files that are opened > for buffered I/O. These operations are usually just too short to have any >

Re: RFR: 8329787: Fix typo in CLDRConverter

2024-04-05 Thread Brian Burkhalter
On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato wrote: > Fix a file/class name in the `CLDRConverter` build tool, with some clean-up > for a switch statement. +1 - Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18662#pullrequestreview-1984005299

Integrated: 8328183: Minor mistakes in docs of PrintStream.append()

2024-04-05 Thread Brian Burkhalter
On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter wrote: > Clarify the behavior of `append` for a `null` `CharSequence` parameter and > clean up a couple of other typos. This pull request has now been integrated. Changeset: 040c9356 Author: Brian Burkhalter URL:

RFR: 8328183: Minor mistakes in docs of PrintStream.append()

2024-04-03 Thread Brian Burkhalter
Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos. - Commit messages: - 8328183: Minor mistakes in docs of PrintStream.append() Changes: https://git.openjdk.org/jdk/pull/18607/files Webrev:

Re: RFR: 8328183: Minor mistakes in docs of PrintStream.append()

2024-04-03 Thread Brian Burkhalter
On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter wrote: > Clarify the behavior of `append` for a `null` `CharSequence` parameter and > clean up a couple of other typos. Item 4 in [this comment](https://bugs.openjdk.org/browse/JDK-8328183?focusedId=14

Re: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128 rounding

2024-04-02 Thread Brian Burkhalter
On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy wrote: > Happened to notice a semantic typo in the description of > MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, > and added some additional information to make the related descriptions more > informative. Looks fine.

Re: RFR: 8328700: Unused import and variable should be deleted in regex package

2024-03-22 Thread Brian Burkhalter
On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti wrote: > Make use of an unused local variable probably intended to replace later casts. Marked as reviewed by bpb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955519288

Re: CFV: New Core Libraries Group Member: Per-Ake Minborg

2024-03-19 Thread Brian Burkhalter
Vote: yes

Re: RFR: 8327786: Add fluent setAccessible()

2024-03-11 Thread Brian Burkhalter
On Mon, 11 Mar 2024 23:06:53 GMT, Sergey wrote: > What is the "standard protocol" to find a reviewer? Reviewers will generally chime in of their own accord depending on their expertise, interest, availability, the perceived importance of the issue, and so on. - PR Comment:

Re: RFR: 8327705: Remove mention of "applet" from java.text package description [v2]

2024-03-11 Thread Brian Burkhalter
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote: >> Removing left over "applet" mention in the package-info doc. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Addressing review comments Marked as reviewed by bpb

Re: RFR: 8327705: Remove mention of "applet" from java.text package description

2024-03-08 Thread Brian Burkhalter
On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato wrote: > Removing left over "applet" mention in the package-info doc. Farewell applets. - Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925759402

Re: RFR: 8327167: Add add() example for Leap Day in Calendar's doc

2024-03-07 Thread Brian Burkhalter
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote: > A simple doc update to include a leap day example in the `Calendar` class. Looks good. - Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923550002

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4]

2024-03-07 Thread Brian Burkhalter
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the >> JDK native codebase. This could be centralized to avoid repeating it again >> and again ! > > Matthias Baesken has updated the pull request incrementally

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3]

2024-03-06 Thread Brian Burkhalter
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the >> JDK native codebase. This could be centralized to avoid repeating it again >> and again ! > > Matthias Baesken has updated the pull request incrementally

Re: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing all bad cases [v2]

2024-03-05 Thread Brian Burkhalter
On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote: >> Fixing test cases. For bad test cases, only the first case was run, and the >> rest were ignored. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflects review

Re: RFR: 8327225: Revert DataInputStream.readUTF to static final

2024-03-04 Thread Brian Burkhalter
On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote: > [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally > removed `final` from the `static final DataInputStream.readUTF` method. This > has a minor compatibility impact (allows hiding the method in a subclass, > while

Result: New Core Libraries Group Member: Raffaello Giulietti

2024-02-28 Thread Brian Burkhalter
The vote for Raffaello Giulietti [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Brian Burkhalter [1] https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119208.html

Re: RFR: JDK-8326530: Widen allowable error bound of Math.tan

2024-02-22 Thread Brian Burkhalter
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote: > Widen acceptable error bound of Math.tan to accommodate the worst-case > observed error which is slightly outside of the allowable range. Looks fine. - Marked as reviewed by bpb (Reviewer). PR Review:

Re: CFV: New Core Libraries Group Member: Viktor Klang

2024-02-20 Thread Brian Burkhalter
Vote: yes

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7]

2024-02-16 Thread Brian Burkhalter
On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via >> Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional > commits since the last

Integrated: 8325990: Remove use of snippet @replace annotation in java.base

2024-02-16 Thread Brian Burkhalter
On Thu, 15 Feb 2024 18:54:46 GMT, Brian Burkhalter wrote: > Revert `@replace` snippet annotation construct to value of `replacement` > attribute. This pull request has now been integrated. Changeset: 7a762520 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/

RFR: 8325990: Remove use of snippet @replace annotation in java.base

2024-02-15 Thread Brian Burkhalter
Revert `@replace` snippet annotation construct to value of `replacement` attribute. - Commit messages: - 8325990: Remove use of snippet @replace annotation in java.base Changes: https://git.openjdk.org/jdk/pull/17882/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17882=00

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-14 Thread Brian Burkhalter
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via > Data- and ObjectInputStream > > Testing: tier1-3 As there are no regression tests added by this request, I assume that existing tests must sufficiently cover

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-14 Thread Brian Burkhalter
On Wed, 14 Feb 2024 10:41:08 GMT, Raffaello Giulietti wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via >> Data- and ObjectInputStream >> >> Testing: tier1-3 > > src/java.base/share/classes/java/io/DataInputStream.java line 585: > >> 583:

CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Brian Burkhalter
, and random number generation. Votes are due by Wednesday, February 28, 2023. Only current Members of the Core Libraries Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Brian

Integrated: 8325152: Clarify specification of java.io.RandomAccessFile.setLength

2024-02-06 Thread Brian Burkhalter
On Fri, 2 Feb 2024 00:38:51 GMT, Brian Burkhalter wrote: > Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to > account for the effect of the method on the file offset as returned by > `getFilePointer`. This pull request has now been integrated. Changeset:

Integrated: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

2024-02-05 Thread Brian Burkhalter
On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation > and with the specification of `Unsafe.reallocateMemory`. This pull request has now been integrated. Changeset: 209d87a8 Author: Brian Burkhalte

Re: RFR: 8325152: Clarify specification of java.io.RandomAccessFile.setLength [v2]

2024-02-02 Thread Brian Burkhalter
> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to > account for the effect of the method on the file offset as returned by > `getFilePointer`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

RFR: 8325152: Clarify specification of java.io.RandomAccessFile.setLength

2024-02-01 Thread Brian Burkhalter
Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to account for the effect of the method on the file offset as returned by `getFilePointer`. - Commit messages: - 8325152: Clarify specification of java.io.RandomAccessFile.setLength Changes:

Re: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

2024-02-01 Thread Brian Burkhalter
On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation > and with the specification of `Unsafe.reallocateMemory`. CSR created. - PR Comment: https://git.openjdk.org/jdk/pull/17643#issuec

Re: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

2024-02-01 Thread Brian Burkhalter
On Thu, 1 Feb 2024 17:01:11 GMT, Roger Riggs wrote: > lgtm Thanks @RogerRiggs. - PR Comment: https://git.openjdk.org/jdk/pull/17643#issuecomment-1922050326

RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

2024-01-30 Thread Brian Burkhalter
Align the specification of `Unsafe.allocateMemory` with its implementation and with the specification of `Unsafe.reallocateMemory`. - Commit messages: - 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value Changes:

Re: RFR: JDK-8323186: A faster algorithm for MutablebigInteger.divWord(long, int) [v4]

2024-01-22 Thread Brian Burkhalter
On Mon, 22 Jan 2024 21:21:53 GMT, fabioromano1 wrote: >> test/jdk/java/math/BigInteger/TestDivWord.java line 5: >> >>> 3: import java.util.Random; >>> 4: >>> 5: public class TestDivWord { >> >> Where is this used in actually jtreg testing? > > @bplb It is not used in jtreg testing. So it is

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2024-01-22 Thread Brian Burkhalter
On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually >> trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last

Re: RFR: JDK-8323186: A faster algorithm for MutablebigInteger.divWord(long, int) [v4]

2024-01-22 Thread Brian Burkhalter
On Mon, 22 Jan 2024 18:52:43 GMT, fabioromano1 wrote: >> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of >> Hacker's Delight (2nd ed), section 9.3, the same used in >> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, >> to get the

Re: RFR: 8320788: The system properties page is missing some properties [v2]

2024-01-09 Thread Brian Burkhalter
On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato wrote: >> Adding an explanation of the locale-related system properties in the >> `System.getProperties()` method. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional > commit since

Re: RFR: JDK-8323186: A faster algorithm for MutablebigInteger.divWord(long, int)

2024-01-08 Thread Brian Burkhalter
On Sat, 6 Jan 2024 18:01:01 GMT, fabioromano1 wrote: > The method `MutableBigInteger.divWord(long, int)` can use the algorithm of > Hacker's Delight (2nd ed), section 9.3, the same used in > `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, > to get the computation

Re: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

2024-01-04 Thread Brian Burkhalter
On Thu, 4 Jan 2024 18:37:59 GMT, Markus KARG wrote: >> No: the third param of >> [Arrays.copyOfRange](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#copyOfRange(byte[],int,int)) >> is `to`, not `len`. > > Ah, this explains why it did not fail originally, but

Re: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

2024-01-04 Thread Brian Burkhalter
On Thu, 4 Jan 2024 18:32:55 GMT, Markus KARG wrote: >> The final position instead of the number of bytes to write was being passed >> to `ByteArrayOuputStream.write(byte[],int,int)`. > > src/java.base/share/classes/java/io/BufferedInputStream.java line 650: > >> 648: } else {

Integrated: 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

2024-01-03 Thread Brian Burkhalter
On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter wrote: > The final position instead of the number of bytes to write was being passed > to `ByteArrayOuputStream.write(byte[],int,int)`. This pull request has now been integrated. Changeset: 54b3ceec Author: Brian Burkhalte

RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

2024-01-03 Thread Brian Burkhalter
The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`. - Commit messages: - 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException Changes:

Re: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

2024-01-03 Thread Brian Burkhalter
On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter wrote: > The final position instead of the number of bytes to write was being passed > to `ByteArrayOuputStream.write(byte[],int,int)`. Everyone was apparently caught off guard as previously `Arrays.copyOfRange(byte[],int,int)` had bee

Re: Integrated: 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java

2024-01-03 Thread Brian Burkhalter
On Wed, 3 Jan 2024 17:13:02 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java. Marked as reviewed by bpb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17249#pullrequestreview-1802749494

Integrated: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

2024-01-02 Thread Brian Burkhalter
On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter wrote: > Add missing comma after 2024. This pull request has now been integrated. Changeset: c2477a5c Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/c2477a5cad6539e6e38cc0732383aaa2a8df801f Stats: 1 line i

RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

2024-01-02 Thread Brian Burkhalter
Add missing comma after 2024. - Commit messages: - 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header Changes: https://git.openjdk.org/jdk/pull/17228/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17228=00 Issue:

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v20]

2024-01-02 Thread Brian Burkhalter
On Tue, 2 Jan 2024 20:00:36 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in >> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in >> `java.io`. >> >> See comment by @vlsi in >>

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v16]

2024-01-02 Thread Brian Burkhalter
On Thu, 21 Dec 2023 17:29:16 GMT, Brian Burkhalter wrote: >> Sergey Tsypanov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request cont

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v16]

2023-12-21 Thread Brian Burkhalter
On Tue, 19 Dec 2023 10:18:11 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in >> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in >> `java.io`. >> >> See comment by @vlsi in >>

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Wed, 20 Dec 2023 22:46:32 GMT, Markus KARG wrote: > So I did not do something wrong but finally I learned Github forensics now. If no crime was committed, I would call it archaeology. - PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1865249242

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Wed, 20 Dec 2023 18:28:27 GMT, Markus KARG wrote: > this icon only says that Alan made change requests I think it's if the "changes requested" button is selected in the "Submit Review" popup under "Files Changed." - PR Comment:

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote: >> Fixes JDK-8322141 >> >> As suggested by @vlsi and documented by @bplb this PR does not return, but >> only sets the maximum result value. > > Markus KARG has updated the pull request incrementally with one additional > commit since the

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Wed, 20 Dec 2023 00:56:16 GMT, Jaikiran Pai wrote: > The updated source change looks fine to me. @jaikiran Thanks for the corroboration. - PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864827299

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Wed, 20 Dec 2023 16:52:38 GMT, Brian Burkhalter wrote: >>> Approved. >>> >>> Please note in future that it is better not to `/integrate` until the >>> request has actually been approved by a Reviewer. >> >> Alan actually did approve them on

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-20 Thread Brian Burkhalter
On Wed, 20 Dec 2023 09:47:05 GMT, Markus KARG wrote: > Alan actually did approve them on December 15. I know, with requested changes. I didn't see the request transition to "Ready" which is where it needs to be to `/integrate`. - PR Comment:

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-19 Thread Brian Burkhalter
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote: >> Fixes JDK-8322141 >> >> As suggested by @vlsi and documented by @bplb this PR does not return, but >> only sets the maximum result value. > > Markus KARG has updated the pull request incrementally with one additional > commit since the

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v4]

2023-12-19 Thread Brian Burkhalter
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote: >> Fixes JDK-8322141 >> >> As suggested by @vlsi and documented by @bplb this PR does not return, but >> only sets the maximum result value. > > Markus KARG has updated the pull request incrementally with one additional > commit since the

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v15]

2023-12-19 Thread Brian Burkhalter
On Tue, 19 Dec 2023 10:14:44 GMT, Sergey Tsypanov wrote: > Shouldn't we keep at least the method for the classes checked in > `BIS.isTrusted()` You can keep it there or inline it. As Alan noted, the main thing is not to add something like a new package. - PR Review Comment:

Re: RFR: 8259637: java.io.File.getCanonicalPath() returns different values for same path [v2]

2023-12-18 Thread Brian Burkhalter
> Modify the `collapse()` function to remove each instance of ".." when the > path is absolute and there is no preceding name. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8259637: Use S

Re: RFR: 8259637: java.io.File.getCanonicalPath() returns different values for same path [v2]

2023-12-18 Thread Brian Burkhalter
On Sun, 17 Dec 2023 08:53:15 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8259637: Use Stream.of in test > > test/jdk/java/io/File/GetCanoni

Integrated: 8259637: java.io.File.getCanonicalPath() returns different values for same path

2023-12-18 Thread Brian Burkhalter
On Wed, 13 Dec 2023 19:37:15 GMT, Brian Burkhalter wrote: > Modify the `collapse()` function to remove each instance of ".." when the > path is absolute and there is no preceding name. This pull request has now been integrated. Changeset: b98d13fc Author:Brian

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v15]

2023-12-15 Thread Brian Burkhalter
On Fri, 15 Dec 2023 19:35:18 GMT, Sergey Tsypanov wrote: > If we drop the method for now I have to write it later again, I guess Maybe, but it's archived so it's easy enough. - PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428601842

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v3]

2023-12-15 Thread Brian Burkhalter
On Fri, 15 Dec 2023 18:34:42 GMT, Markus KARG wrote: > I quickly drafted an absolute minimal test for this in [2aaac63] [...]. This test does not fail for me when run against my local build of the current mainline. Usually, unless randomness is involved, a test should fail before the proposed

Re: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred [v2]

2023-12-15 Thread Brian Burkhalter
On Fri, 15 Dec 2023 09:55:36 GMT, Alan Bateman wrote: > [...] maybe we need to come up with tests that quickly check the handling at > this limit. @mkarg Do you intend to provide any such test as part of this request? - PR Comment:

Re: [jdk22] RFR: 8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

2023-12-15 Thread Brian Burkhalter
On Fri, 15 Dec 2023 17:41:43 GMT, Naoto Sato wrote: > 8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are > incorrect Marked as reviewed by bpb (Reviewer). - PR Review: https://git.openjdk.org/jdk22/pull/16#pullrequestreview-1784673248

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v15]

2023-12-15 Thread Brian Burkhalter
On Fri, 15 Dec 2023 09:25:00 GMT, Sergey Tsypanov wrote: > I think this would be doing double job, wouldn't it? Sorry, I don't understand. - PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428236374

Re: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v7]

2023-12-14 Thread Brian Burkhalter
On Thu, 14 Dec 2023 21:54:53 GMT, Markus KARG wrote: >> I mean SequenceInputStream, not the base class: >> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/SequenceInputStream.java#L249 >> >> Could you please double-check? > >

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v15]

2023-12-14 Thread Brian Burkhalter
On Thu, 14 Dec 2023 08:47:03 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in >> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in >> `java.io`. >> >> See comment by @vlsi in >>

Re: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v7]

2023-12-14 Thread Brian Burkhalter
On Thu, 14 Dec 2023 06:12:40 GMT, Vladimir Sitnikov wrote: > What do you think? I think that you are looking at an obsolete repository: https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802 - PR

Re: RFR: 8259637: java.io.File.getCanonicalPath() returns different values for same path

2023-12-13 Thread Brian Burkhalter
On Wed, 13 Dec 2023 19:37:15 GMT, Brian Burkhalter wrote: > Modify the `collapse()` function to remove each instance of ".." when the > path is absolute and there is no preceding name. Without this change the updated test fails as: FAILED GetCanonicalPath::g

RFR: 8259637: java.io.File.getCanonicalPath() returns different values for same path

2023-12-13 Thread Brian Burkhalter
Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name. - Commit messages: - 8259637: java.io.File.getCanonicalPath() returns different values for same path Changes: https://git.openjdk.org/jdk/pull/17089/files

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-06 Thread Brian Burkhalter
On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Create RandomBigIntegers.java >> >> Create a benchmark to measure the p

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-05 Thread Brian Burkhalter
On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually >> trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last

Integrated: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted

2023-12-05 Thread Brian Burkhalter
On Thu, 30 Nov 2023 00:03:21 GMT, Brian Burkhalter wrote: > Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. This pull request has now been integrated. Changeset: b0d14509 Author:

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v7]

2023-12-05 Thread Brian Burkhalter
> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: Fix over

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v6]

2023-12-05 Thread Brian Burkhalter
> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: s/tmp/

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v4]

2023-12-05 Thread Brian Burkhalter
On Tue, 5 Dec 2023 12:58:45 GMT, Markus KARG wrote: >> I suspect it's left over from a previous iteration. In any case, limiting it >> to a small number of output streams makes this easier to look at. BAOS and >> FOS seem okay, POP seems okay too but legacy and not interesting. > >> I suspect

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v5]

2023-12-05 Thread Brian Burkhalter
> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: Remove p

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-04 Thread Brian Burkhalter
On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually >> trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v4]

2023-12-04 Thread Brian Burkhalter
> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: inst

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v3]

2023-12-04 Thread Brian Burkhalter
> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of > `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: Constrain t

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v3]

2023-12-04 Thread Brian Burkhalter
On Sat, 2 Dec 2023 03:48:46 GMT, jmehrens wrote: >> I think that a sufficiently future-proof deny list could be had by changing >> >> 211 if (out.getClass().getPackageName().startsWith("java.") && >> >> back to >> >> 211 if

Re: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v2]

2023-12-01 Thread Brian Burkhalter
On Fri, 1 Dec 2023 22:26:51 GMT, Brian Burkhalter wrote: >> I see the problem that unless we have an explicit whitelist, we do open the >> risk of accidentially adding another wrapper stream in future to the JDK >> somewhere and forget to add it to the blacklist. So f

  1   2   3   4   5   6   7   >