On Sat, 17 May 2025 19:42:39 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/java/ea
On Sat, 17 May 2025 19:42:39 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/java/ea
On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote:
>> In offline discussion, we noted that the documentation on this annotation
>> does not recommend minimizing the intrinsified section and moving whatever
>> can be done in Java to Java; thus I prepared this documentation update, to
>> shrink
On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote:
>> In offline discussion, we noted that the documentation on this annotation
>> does not recommend minimizing the intrinsified section and moving whatever
>> can be done in Java to Java; thus I prepared this documentation update, to
>> shrink
On Fri, 16 May 2025 19:55:58 GMT, John R Rose wrote:
>> Chen Liang 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 contains eight additional
>> commits s
On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong wrote:
>> Ping again~ could any one please take a look at this PR？ Thanks a lot!
>
>> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing
>> and get back.
>>
>> Do you have any idea about following regression?
>>
>> ```
>>
On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong wrote:
>> Ping again~ could any one please take a look at this PR？ Thanks a lot!
>
>> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing
>> and get back.
>>
>> Do you have any idea about following regression?
>>
>> ```
>>
> This is the implementation of the draft [JEP: Ahead-of-time Command Line
> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
> cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_O
Hello!
I created PR is scope of jenkins-core project:
https://github.com/jenkinsci/jenkins/pull/10659
Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675
In this PR i propped to override
protected Object getClassLoadingLock(String className)
method and use weak references for lock objects
On Mon, 19 May 2025 03:10:46 GMT, Xiaohong Gong wrote:
>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs
>> for X86 platforms [1]. However, the current implementation is not optimal
>> for AArch64 SVE platform, which natively supports vector instructions for
>> sub
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
> @ 9 java.lang.String:: (12 bytes) inline (hot)
> !m
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
> @ 9 java.lang.String:: (12 bytes) inline (hot)
> !m
> This is the implementation of the draft [JEP: Ahead-of-time Command Line
> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
> cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_O
On Tue, 20 May 2025 01:21:34 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/String.java line 690:
>>
>>> 688: .onUnmappableCharacter(CodingErrorAction.REPLACE);
>>> 689: char[] ca = new char[en];
>>> 690: int caLen = decodeWithDecoder(cd, ca, byt
On Sun, 18 May 2025 20:44:12 GMT, Chen Liang wrote:
>> Through JVM Option +PrintInlining, we found that String has a constructor
>> codeSize of 852, which is too large. This caused failed to inline.
>>
>> The following is the output information of PrintInlining:
>>
>> @ 9 jav
On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote:
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
> @ 9 java.lan
On Tue, 20 May 2025 00:49:28 GMT, Henry Jen wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year in
>> test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.
>
> Marked as reviewed by h
On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote:
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
> @ 9 java.lan
Through JVM Option +PrintInlining, we found that String has a constructor
codeSize of 852, which is too large. This caused failed to inline.
The following is the output information of PrintInlining:
@ 9 java.lang.String:: (12 bytes) inline (hot)
!m @ 1 java.
Fixed jpackage to produce valid Java runtimes based on description below:
Definitions:
- JDK bundle defined as bundle which contains "Contents/Home",
"Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
- Signed JDK bundle contains all files as JDK bundle +
"Contents/_CodeSignature".
- JDK
On Mon, 19 May 2025 18:30:20 GMT, Roger Riggs wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> simplify code
>
> src/java.base/share/classes/java/util/UUID.java line 491:
>
>> 489: * hexadecimal representation,
On Mon, 19 May 2025 19:56:52 GMT, Jiangli Zhou wrote:
>> @sendaoYan Please let me know if you have any additional review comments,
>> thanks.
>>
>> Also looking for a 'R'eviewer for reviewing. Thanks!
>
> A friendly ping
LGTM.
-
PR Review Comment: https://git.openjdk.org/jdk/pull
On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou wrote:
>> Please review this PR for skipping
>> jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
>> context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>>
>> jdk/test/lib/process/TestNativeProcessBuild
On Mon, 19 May 2025 23:50:59 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/util/Locale.java line 2792:
>>
>>> 2790: * tag). {@code languageTag} may contain up to three extlang
>>> subtags.
>>> 2791: + For such occurrences, the first extlang subtag is used as
>>> t
On Mon, 19 May 2025 23:41:25 GMT, Naoto Sato wrote:
>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts
>> _extlang_ subtags in the input as well as what behavior occurs.
>> Additionally, both this method and `Locale.forLanguageTag(String)` should
>> mention their behavior
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally with one a
On Mon, 19 May 2025 20:56:55 GMT, Justin Lu wrote:
> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts
> _extlang_ subtags in the input as well as what behavior occurs. Additionally,
> both this method and `Locale.forLanguageTag(String)` should mention their
> behavior when
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally with one a
On Mon, 19 May 2025 20:17:43 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
>
On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero wrote:
> This PR is defining a new internal annotation,
> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
> that an argument to a given method or cons
On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote:
>> This PR is defining a new internal annotation,
>> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
>> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
>> that an argument to a given method or
What I mean by central in this context isn't that it's at the core of
things and features are built on top of it - as you note it is a valid
transformation of the hierarchy.
What I mean is that absent other construction/deconstruction apis it is the
most convenient avenue for those tasks. So code
> From: "Paul Sandoz"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "core-libs-dev"
>
> Sent: Monday, May 19, 2025 11:18:26 PM
> Subject: Re: Towards a JSON API for the JDK
> Those extending the non-sealed subtypes of JsonValue must conform to the
> requirements that are specified. The current docum
Those extending the non-sealed subtypes of JsonValue must conform to the
requirements that are specified. The current documentation could be more
clearly written as to what those requirements are. Of course we cannot enforce
those requirements any more than we can enforce the requirements specif
It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_
subtags in the input as well as what behavior occurs. Additionally, both this
method and `Locale.forLanguageTag(String)` should mention their behavior when
more than three _extlang_ subtags are provided. This PR clari
Paul,
thank you for picking up the topic JSON. I do like the simplicity of
your proposal, OTOH I have concerns:
* Will it it be sustaining?
We added a XML API when XML was "the" big thing, and now it is not a big
thing anymore and we can't get rid of the XML API without breaking
things. So
> From: "Paul Sandoz"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "core-libs-dev"
>
> Sent: Monday, May 19, 2025 10:02:50 PM
> Subject: Re: Towards a JSON API for the JDK
>> On May 19, 2025, at 8:16 AM, Remi Forax wrote:
>> Okay,
>> i've taken a look to the design and this is not pretty.
> That
On Mon, 19 May 2025 19:24:57 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88:
On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
>>
>>> 1339: * @throws ClassNotFoundException if one of the component classes
>>> cannot be resolved
>>> 1340: * @see MethodType.readResolve()
>>> 1341:
On Mon, 19 May 2025 19:27:27 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/sun/nio/Cleaner.java line 31:
>
>> 29: * {@cod
Hi Cay,
It would be really helpful to share some more detailed use-cases on
editing/modification that you may reasonably expect users to perform.
I hope we might be able to devise a transformation API, hopefully layered on
top of the public API and possibly with structural sharing for unmodifie
The approach to the design of this API leans heavily on ongoing and future
language and library features. This is why the API is so small as we don’t want
conflicts with what we may do in the future. In the document we briefly mention
data binding but don’t provide further context:
Advanced fea
On Mon, 19 May 2025 18:30:45 GMT, ExE Boss wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Bits.java line 145:
>
>> 143:
On Mon, 19 May 2025 19:37:58 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
>>
>>> 207: super(-1, 0, cap, cap, fd, isSync, segment);
>>> 208: address = addr;
>>> 209:cleaner = (unmapper == null) ? null :
>>> Buffer
On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote:
> When the test java/io/File/GetXSpace.java fails, because the usable space is
> greater than the free space, the values in the exception are not the correct
> ones.
@ArnoZeller Please issue the `/integrate` command so that this request may
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request with a new target base d
On May 19, 2025, at 8:16 AM, Remi Forax wrote:
Okay,
i've taken a look to the design and this is not pretty.
That seems an exaggerated statement to me. It's a trade-off, a compromise,
allowing others to implement their own parsers, perhaps from non-textual
representations. So of course we c
On Thu, 15 May 2025 17:15:20 GMT, Jiangli Zhou wrote:
>> test/lib-test/TEST.ROOT line 31:
>>
>>> 29: keys=randomness
>>> 30:
>>> 31: # Minimum jtreg version
>>
>> Shoule we update the copyright year for file TestNativeProcessBuilder.java
>
> @sendaoYan Please let me know if you have any additi
On May 17, 2025, at 4:37 AM, Ethan McCue wrote:
I think it's worth noting that the way you used the prospective API in your
ONNX code is not representative of how the API would generally be used in a
jdk-only scenario. Custom making a general transformation from JsonValue ->
Record is outsid
>
> This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing
> one particular encoding of JSON and making it central to the API. Is that
> really the most important encoding?
>
It's one opinionated kind, a simple bi-directional mapping
(embedding-projection pair) based on
On Mon, 19 May 2025 18:40:56 GMT, ExE Boss wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
>
On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>>
On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote:
>> This PR is defining a new internal annotation,
>> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
>> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
>> that an argument to a given method or
On Sun, 18 May 2025 20:50:41 GMT, Kim Barrett wrote:
>> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
>>
>>> 24: */
>>> 25:
>>> 26: package jdk.internal.nio;
>>
>> The implementation/internal classes for this area are in sun.nio (for
>> historical reasons). Probably best
On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote:
>> Similar to PR #24982
>> Document preconditions on certain DecimalDigits methods that use operations
>> either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit sinc
On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>>
On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
> S
On Mon, 19 May 2025 13:33:51 GMT, kieran-farrell wrote:
> With the recent approval of UUIDv7
> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static
> method UUID.timestampUUID() which constructs and returns a UUID in support of
> the new time generated UUID version.
>
On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote:
>> Similar to PR #24982
>> Document preconditions on certain DecimalDigits methods that use operations
>> either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit sinc
> Get JDK 26 underway.
Nizar Benalla has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains nine commits:
- Update --release 25 symbol information for JDK 25 build 23
The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
-
Hi,
On 5/17/25 10:55 PM, Cay Horstmann wrote:
PS. Trying to create and show the youthful John gives me grief right now:
Json.fromUntyped(Map.of("name", "John", "age", 30)).toString()
| Exception java.lang.NullPointerException: Cannot read the array
length because "value" is null
| at
On Mon, 19 May 2025 17:34:16 GMT, Raffaello Giulietti
wrote:
>> Yes, but perhaps in the current version it's more clear what is the returned
>> value according to the condition.
>
> One could see the suggested variant as "return magBitLength(), except for a
> corrective term in case blah blah.
On Mon, 19 May 2025 17:16:58 GMT, fabioromano1 wrote:
>> I think the suggestion is fine.
>
> Yes, but perhaps in the current version it's more clear what is the returned
> value according to the condition.
One could see the suggested variant as "return magBitLength(), except for a
corrective t
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> Implementation of Comparator.min and Comparator.max methods. Preliminary
> discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and C
On Mon, 19 May 2025 17:10:50 GMT, Brian Burkhalter wrote:
>> This change proposes to modify `java.io.File.delete()` so that regular files
>> on Windows will not be deleted by default if their read-only attribute is
>> set. A boolean-valued system compatibility property
>> `jdk.io.File.deleteRe
On 19/05/2025 15:34, Robert Stupp wrote:
Hi,
I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547.
TL;DR java.lang.ClassLoader.definePackage() (the one taking 8
arguments) clearly defines that a IllegalArgumentException is thrown,
"if a package of the given name is already
On Mon, 19 May 2025 15:50:10 GMT, Raffaello Giulietti
wrote:
>> What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since
>> `bitLength()` does not access to `static` fields and `BigInteger` is not
>> threadsafe, and therefore no race conditions occur?
>
> I think the suggest
On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote:
>> For the ratio behind this please see the companion CSR:
>> https://bugs.openjdk.org/browse/JDK-8357180.
>>
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>>
>> This patch just writes a deprecation message to stderr:
Developers use JSON libraries like Fastjson, Jackson and Gson primarily
(my claim) because they can marshal between JSON files and POJOs in one
line of code with great performance and can easily tweak the mapping
using annotations or adapter classes.
Being able to read/write a JSON file from/to
On Mon, 19 May 2025 15:57:14 GMT, Alan Bateman wrote:
> I think that would be simpler and means the `@EnabledOnOs` usages would go
> away, but it's up to you.
I agree that is better. So changed in
[74e1698](https://github.com/openjdk/jdk/pull/24977/commits/74e16983c94d9b29c91b660e8a025388d72ae
> This change proposes to modify `java.io.File.delete()` so that regular files
> on Windows will not be deleted by default if their read-only attribute is
> set. A boolean-valued system compatibility property
> `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if
> desired.
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> Implementation of Comparator.min and Comparator.max methods. Preliminary
> discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and C
On Mon, 19 May 2025 15:58:17 GMT, Alan Bateman wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use string block
>
> src/java.base/unix/classes/java/lang/ProcessImpl.java line 111:
>
>> 109:
> For the ratio behind this please see the companion CSR:
> https://bugs.openjdk.org/browse/JDK-8357180.
>
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>
> This patch just writes a deprecation message to stderr:
>
>
> 08:46:38 thomas@starfish java -Djdk.lang.Process.launch
On Thu, 1 May 2025 19:05:50 GMT, Stuart Marks wrote:
> Collections.synchronizedList() returns a List implementation that doesn't do
> proper locking. This PR does the following on the synchronized wrapper:
>
> - overrides and adds locking to SequencedCollection methods;
> - performs instance ma
On Mon, 19 May 2025 15:18:12 GMT, David Beaumont wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a l
On Mon, 19 May 2025 15:18:12 GMT, David Beaumont wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a l
On Mon, 19 May 2025 12:54:37 GMT, Jaikiran Pai wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed test.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:
>
>> 222: // Underlying file is rea
On Sun, 18 May 2025 21:15:21 GMT, Chen Liang wrote:
> > Did you consider calling getComponentType(), which already returns the
> > field?
>
> I don't think we want an extra indirection here - The logic here is quite
> simple. Counterargument could be that `MethodType::descriptorString` calls
On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N wrote:
> This PR adds missing classpath exception
This pull request has now been integrated.
Changeset: afcaf840
Author:Sorna Sarathi N
Committer: Jaikiran Pai
URL:
https://git.openjdk.org/jdk/commit/afcaf84022f165d66068c16460b7666f
On Sun, 23 Feb 2025 11:32:41 GMT, Robert Stupp wrote:
> Concurent calls to `ClassLoader.definePackage()` can yield
> `IllegalArgumentException`s if the package is already defined. Some built-in
> class loaders, like `URLClassLoader`, already handle this case, but custom
> class loaders (would)
On Mon, 19 May 2025 13:31:04 GMT, David Beaumont wrote:
>> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
>>
>>> 206: // Multi-release JARs, when opened with a specified version
>>> are inherently read-only.
>>> 207: Path multiReleaseJar = createMultiReleaseJar();
>>>
On Sat, 17 May 2025 19:42:39 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/java/ea
On Sun, 18 May 2025 02:18:24 GMT, Chen Liang 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/java/
On Sun, 18 May 2025 02:17:46 GMT, Chen Liang 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/java/
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.invoke.Met
On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote:
>> This PR is defining a new internal annotation,
>> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
>> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
>> that an argument to a given method or
On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote:
> For the ratio behind this please see the companion CSR:
> https://bugs.openjdk.org/browse/JDK-8357180.
>
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>
> This patch just writes a deprecation message to stderr:
>
>
On Mon, 19 May 2025 15:20:25 GMT, Brian Burkhalter wrote:
>> Split the test method in half for Unix and Windows in
>> [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).
>
>> The behavior and system property is Windows specific and might make th
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed numberOfTrailingZeros() as a duplicate of the cach
On Fri, 16 May 2025 13:30:01 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 3860:
>>
>>> 3858: && Integer.lowestOneBit(mag[0]) == mag[0]
>>> 3859: && numberOfTrailingZeroInts() == mag.length - 1
>>> 3860: ? magBi
On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote:
> For the ratio behind this please see the companion CSR:
> https://bugs.openjdk.org/browse/JDK-8357180.
>
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>
> This patch just writes a deprecation message to stderr:
>
>
On Fri, 16 May 2025 17:22:14 GMT, Brian Burkhalter wrote:
>> I guess collapsing the tests made them more ambiguous. Will fix.
>
> Split the test method in half for Unix and Windows in
> [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).
> The
On Mon, 19 May 2025 15:03:51 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 5034:
>>
>>> 5032: */
>>> 5033: private byte[] magSerializedForm() {
>>> 5034: byte[] result = new byte[(magBitLength() + 7) >>> 3];
>>
>> I think there's
> Adding read-only support to ZipFileSystem.
>
> The new `accessMode` environment property allows for readOnly and readWrite
> values, and ensures that the requested mode is consistent with what's
> returned.
>
> This involved a little refactoring to ensure that "read only" state was set
> ini
Okay,
i've taken a look to the design and this is not pretty.
The main issue is that the javadoc claims that
"Both JsonValue instances and their underlying values are immutable."
but at the same time any subtypes of JsonValue is non-sealed so anyone can
implement let say JsonString and adds i
On Mon, 19 May 2025 15:02:57 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> An optimization
>
> src/java.base/share/classes/java/math/BigInteger.java line 5034:
>
>> 5032: */
>> 503
On Fri, 16 May 2025 11:10:12 GMT, fabioromano1 wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last revision
> Adding read-only support to ZipFileSystem.
>
> The new `accessMode` environment property allows for readOnly and readWrite
> values, and ensures that the requested mode is consistent with what's
> returned.
>
> This involved a little refactoring to ensure that "read only" state was set
> ini
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> I'm not sure whether we should specify exactly the behavior in case if the
> comparator returns 0. I feel that it could be a useful invariant that
> `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different
> argument,
1 - 100 of 154 matches
Mail list logo
