> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
>
> A couple of `@see` tags in the [serialization
> page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.
> 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
On Thu, 22 May 2025 10:52:44 GMT, Daniel Fuchs wrote:
>> Hello Daniel, with this proposed change, is there any reason to have the
>> `localSource` field in this `TimeSource` anymore?
>
> Yes. It avoids the volatile read on nanoSource.
It could serve as a safety net. But I can also revert this a
On Wed, 21 May 2025 13:42:39 GMT, Per Minborg wrote:
>> 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
On Wed, 21 May 2025 17:55:17 GMT, Valerie Peng wrote:
>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
>> line 459:
>>
>>> 457:
>>> 458: boolean pending = false;
>>> 459: NIO_ACCESS.acquireSession(buf);
>>
>> Here, we acquire the sess
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
> on another thread) `localSource`. This was confirmed by put
On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla wrote:
>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>>
>> A couple of `@see` tags in the [serialization
>> page](https://download.java.net/ja
On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
> respectively.
>
> CSR is underway.
>
> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
> API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net
> jck:api/javax_security jck:ap
We observed a case where the instants returned by `TimeSource.now()` were
returned in non-monotonic order. The reason was that sometimes we were using a
delay calculated with one `localSource` as an input to a different (updated on
another thread) `localSource`. This was confirmed by putting `as
On Thu, 22 May 2025 09:53:26 GMT, Daniel Jeliński wrote:
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
>
On Thu, 22 May 2025 09:59:58 GMT, Daniel Fuchs wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (updated
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
On Thu, 22 May 2025 10:35:57 GMT, Jaikiran Pai wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java
>> line 97:
>>
>>> 95: // use localSource if possible to avoid a volatile read
>>> 96: if (source.isInWindow(delay)) {
>>> 97: return
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
On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs 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.op
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
On Wed, 21 May 2025 16:50:28 GMT, Mikhail Yankelevich
wrote:
>> 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
On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
> on another thread) `localSource`. This was confirmed by put
20 matches
Mail list logo
