Re: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3]

2025-05-21 Thread Alan Bateman
On Wed, 21 May 2025 05:00:16 GMT, Valerie Peng wrote: > > A question for folks on security-dev. Are there tests for Cipher.doFinal, > > CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer > > obtained from a memory segment? > > I don't find any. We'd have to update them to c

RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

2025-05-21 Thread Jaikiran Pai
Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406. As noted in the linked issue, this system property is no longer supported by

Re: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

2025-05-21 Thread Volkan Yazici
On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the usage of > the outdated `jdk.tracePinnedThreads` system property from the httpclient > tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406. > > As noted in

RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner

2025-05-21 Thread Volkan Yazici
There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charse

Re: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

2025-05-21 Thread Daniel Fuchs
On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the usage of > the outdated `jdk.tracePinnedThreads` system property from the httpclient > tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406. > > As noted in

Re: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7]

2025-05-21 Thread Valerie Peng
On Tue, 20 May 2025 11:01:46 GMT, Per Minborg wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix copyright year > > src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java > line 459: > >

Re: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner

2025-05-21 Thread Alan Bateman
On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and > `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the > default charset. As recommended by the recently merged > [JDK-8356420](https://bugs.open

Re: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

2025-05-21 Thread SendaoYan
On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the usage of > the outdated `jdk.tracePinnedThreads` system property from the httpclient > tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406. > > As noted in

Re: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner

2025-05-21 Thread Roger Riggs
On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and > `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the > default charset. As recommended by the recently merged > [JDK-8356420](https://bugs.open

Re: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3]

2025-05-21 Thread Per Minborg
On Wed, 21 May 2025 09:10:57 GMT, Alan Bateman wrote: > > > A question for folks on security-dev. Are there tests for Cipher.doFinal, > > > CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer > > > obtained from a memory segment? > > > > > > I don't find any. We'd have to u

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v2]

2025-05-21 Thread Mikhail Yankelevich
On Tue, 20 May 2025 16:58:02 GMT, Daniel Fuchs wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one >> additional commit since the last revision: >> >> addressing comments > > src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 409: > >> 407:

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v2]

2025-05-21 Thread Mikhail Yankelevich
On Tue, 20 May 2025 17:17:21 GMT, Daniel Jeliński wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one >> additional commit since the last revision: >> >> addressing comments > > src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 246: > >> 2

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v2]

2025-05-21 Thread Mikhail Yankelevich
On Tue, 20 May 2025 17:20:26 GMT, Daniel Jeliński wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 252: >> >>> 250: selector.wakeup(); >>> 251: long latest = System.nanoTime() + delay * 10L; >>> 252: while (System.nanoTime() < lat

Re: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v6]

2025-05-21 Thread Per Minborg
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than > `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment > instances can be used in classes that were not covered by > https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3

Re: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7]

2025-05-21 Thread Per Minborg
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than > `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment > instances can be used in classes that were not covered by > https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3

Re: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

2025-05-21 Thread Daniel Jeliński
On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the usage of > the outdated `jdk.tracePinnedThreads` system property from the httpclient > tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406. > > As noted in

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v3]

2025-05-21 Thread Mikhail Yankelevich
On Tue, 20 May 2025 17:05:32 GMT, Daniel Fuchs wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one >> additional commit since the last revision: >> >> cleanup > > test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 128: > >> 126: >> 127:

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v3]

2025-05-21 Thread Mikhail Yankelevich
> HttpServer::stop will terminate the server immidiately after all exhcnages > are complete. > If the exchanges take longer then the specified delay it will terminate > straight after the delay, the same as the previous behaviour. > > Used to wait until the delay is complete at all times, regard

Re: RFR: 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress [v2]

2025-05-21 Thread Mikhail Yankelevich
> HttpServer::stop will terminate the server immidiately after all exhcnages > are complete. > If the exchanges take longer then the specified delay it will terminate > straight after the delay, the same as the previous behaviour. > > Used to wait until the delay is complete at all times, regard