Hi wenshao,
I think this is a very good proposal that makes code much cleaner. This allows
us to migrate this context to value classes in the future for better
optimization, improves the thread safety of the optional status tracking
(compared to throwing exceptions), and makes the context thread
On Fri, 19 Sep 2025 01:39:52 GMT, Chen Liang wrote:
>> String.repeat() cannot generate a string whose total length exceeds
>> Integer.MAX_VALUE due to internal limits. That’s why I used a small chunk
>> and accumulated UTF-8 length in a loop.It seems that the String type cannot
>> hold a strin
On Thu, 18 Sep 2025 12:59:48 GMT, Guanqiang Han wrote:
> Creating a string of Integer.MAX_VALUE/2 characters would require enormous
> memory
See test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java
-
PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-331055
> This PR loads the classes for the boot/platform/app loaders with
> `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very
> beginning of `vmClasses::resolve_all()`, before any Java code is executed.
>
> - We essentially iterate over all the classes inside the
> `AOTLinkedCla
On Thu, 18 Sep 2025 22:34:52 GMT, Chen Liang wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add @implSpec
>
> src/java.base/share/classes/java/util/Comparator.java line 201:
>
>> 199: * @param o1 an a
On Fri, 19 Sep 2025 02:25:50 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/util/Comparator.java line 201:
>>
>>> 199: * @param o1 an argument.
>>> 200: * @param o2 another argument.
>>> 201: * @paramthe type of the arguments and the result.
>>
>> Since
On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote:
>> This PR introduces a new efficient API for appending two-digit integers to
>> StringBuilders and refactors DateTimeHelper to leverage this new
>> functionality.
>>
>> Changes include:
>>
>> 1. New `appendPair` method for efficient two-di
On Tue, 9 Sep 2025 15:31:40 GMT, David Beaumont wrote:
>> The writer field of the handler needs to be re-checked for null inside the
>> locked region before use.
>
> David Beaumont has updated the pull request incrementally with one additional
> commit since the last revision:
>
> License fi
On Wed, 10 Sep 2025 09:33:42 GMT, Andrew Haley wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 74 commits:
>>
>> - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>> - * iwalulya: remove con
On Wed, 17 Sep 2025 19:05:37 GMT, Ashutosh Mehra wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added logging about @AOTSafeClassInitializer classes that have not been
>> initialized
>
> src/hotspot/share/cds/aotClass
On Wed, 17 Sep 2025 19:08:46 GMT, Ashutosh Mehra wrote:
> > Note, the check of the above requirement has been moved to
> > AOTClassInitializer::check_aot_annotations(). The previous check in
> > ClassFileParser was not executed because the class is loaded in the AOT
> > training run, where CDS
> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a)
> initialized in the AOT assembly phase, and (b) stored in the AOT cache in an
> already initialized state. This means that all the static fields in this
> class will be immediately available upon JVM bootstrap when
On Fri, 19 Sep 2025 01:15:14 GMT, Guanqiang Han wrote:
>> test/jdk/jdk/internal/util/TestUtfLen.java line 50:
>>
>>> 48: for (int i = 0; i < iterations; i++) {
>>> 49: total += ModifiedUtf.utfLen(chunk, 0);
>>> 50: }
>>
>> Suggestion:
>>
>> long total = Modi
I propose to make j.t.f.DateTimePrintContext immutable.
Currently, DateTimePrintContext has only one mutable field, optional. This can
be replaced by adding an optional parameter to the DateTimeFormatter.formatTo
method.
Immutable DateTimePrintContext can be optimized by escape analysis, such as
On Thu, 18 Sep 2025 15:27:43 GMT, Chen Liang wrote:
>> Guanqiang Han 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 three additional
>> commits
On Mon, 15 Sep 2025 03:15:55 GMT, Chen Liang wrote:
> This solution, if it is to be accepted, can only be a stopgap measure - I
> think the most likely feature to replace this hack would be String Templates.
> What abilities do you think that String Templates should support so that you
> can c
On Thu, 18 Sep 2025 22:25:02 GMT, Alexey Semenyuk wrote:
> Introduce `jdk.jpackage.internal.SystemEnvironment` interface to describe
> system tools needed for building specific package bundles with three
> immediate subinterfaces: `WinSystemEnvironment`, `LinuxSystemEnvironment`,
> and `MacDmg
> The Signature modeling in the ClassFile API is missing some validations
> required by JVMS, notably identifier character restrictions and void type
> restrictions. In addition, the model currently uses `ClassDesc` to indicate a
> simple name for an inner class signature, which is incorrect, an
The Signature modeling in the ClassFile API is missing some validations
required by JVMS, notably identifier character restrictions and void type
restrictions. In addition, the model currently uses `ClassDesc` to indicate a
simple name for an inner class signature, which is incorrect, and this p
On Thu, 18 Sep 2025 22:31:17 GMT, Justin Lu wrote:
>> Please review this PR which addresses an edge case for
>> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
>> hour to remain the same as before the call. After this change, the expected
>> hour is returned. That is,
Introduce `jdk.jpackage.internal.SystemEnvironment` interface to describe
system tools needed for building specific package bundles with three immediate
subinterfaces: `WinSystemEnvironment`, `LinuxSystemEnvironment`, and
`MacDmgSystemEnvironment`.
`LinuxSystemEnvironment` has two subinterfaces
On Sun, 3 Aug 2025 13:42:41 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 an
> Please review this PR which addresses an edge case for
> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
> hour to remain the same as before the call. After this change, the expected
> hour is returned. That is, rolling a full cycle for HOUR (12 hours) and
> HOUR_OF_
On Thu, 18 Sep 2025 22:31:17 GMT, Justin Lu wrote:
>> Please review this PR which addresses an edge case for
>> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
>> hour to remain the same as before the call. After this change, the expected
>> hour is returned. That is,
On Sun, 3 Aug 2025 13:42:41 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 an
On Thu, 18 Sep 2025 20:41:58 GMT, Justin Lu wrote:
>> Please review this PR which addresses an edge case for
>> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
>> hour to remain the same as before the call. After this change, the expected
>> hour is returned. That is,
On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote:
> During parse routines, DecimalFormat uses DigitList to append digits from the
> parsed text.
>
> Note that `digit` is always the int value 0 through 9 (and subsequently the
> code point 48 through 57) when passed to `append`.
>
> Currently,
On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote:
> During parse routines, DecimalFormat uses DigitList to append digits from the
> parsed text.
>
> Note that `digit` is always the int value 0 through 9 (and subsequently the
> code point 48 through 57) when passed to `append`.
>
> Currently,
With the introduction of [8336856: Efficient hidden class-based string
concatenation strategy](https://github.com/openjdk/jdk/pull/20273) , the
StringConcatFactory#generateMHInlineCopy method is no longer used by default.
After a year of community use, the InlineHiddenClassStrategy has proven to
On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote:
> During parse routines, DecimalFormat uses DigitList to append digits from the
> parsed text.
>
> Note that `digit` is always the int value 0 through 9 (and subsequently the
> code point 48 through 57) when passed to `append`.
>
> Currently,
On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the
>> HTTP Client API](htt
On Thu, 18 Sep 2025 21:25:13 GMT, Roger Riggs wrote:
> Propagate [backout] Change java.time month/day field types to 'byte' to jdk
> 25.
> Previously reviewed as: https://github.com/openjdk/jdk/pull/27346
Wrong backport target.
-
PR Comment: https://git.openjdk.org/jdk/pull/27375#
On Thu, 18 Sep 2025 21:25:13 GMT, Roger Riggs wrote:
> Propagate [backout] Change java.time month/day field types to 'byte' to jdk
> 25.
> Previously reviewed as: https://github.com/openjdk/jdk/pull/27346
This pull request has been closed without being integrated.
-
PR: https://gi
Propagate [backout] Change java.time month/day field types to 'byte' to jdk 25.
Previously reviewed as: https://github.com/openjdk/jdk/pull/27346
-
Commit messages:
- Backport 0756ecb214b8ab76cb69f354063d153b72f978c2
Changes: https://git.openjdk.org/jdk/pull/27375/files
Webrev: ht
On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote:
> During parse routines, DecimalFormat uses DigitList to append digits from the
> parsed text.
>
> Note that `digit` is always the int value 0 through 9 (and subsequently the
> code point 48 through 57) when passed to `append`.
>
> Currently,
On Thu, Sep 18, 2025 at 7:08 PM Brian Burkhalter
wrote:
> I have filed an issue to improve the specification of this method somehow:
>
> https://bugs.openjdk.org/browse/JDK-8368007
>
Personally, a better spec wouldn't have helped me avoid the trap. The
spec is already clear. I think it's the c
On Tue, 16 Sep 2025 23:14:13 GMT, Joe Darcy wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> An empty commit to kick GHA
>
> Okay -- while some of the changes here are clearly bugs, that doesn't obviate
> the need f
On Thu, 18 Sep 2025 15:39:25 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - + - to - in comment
>> - DST test cases + compute expected value as method + improve err msg
>
> test/jdk/java/util/Cale
> Please review this PR which addresses an edge case for
> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
> hour to remain the same as before the call. After this change, the expected
> hour is returned. That is, rolling a full cycle for HOUR (12 hours) and
> HOUR_OF_
On Wed, 17 Sep 2025 15:10:49 GMT, Pavel Rappo wrote:
>> Please review this documentation-only change, which I believe does **NOT**
>> require CSR.
>>
>> The change touches java.time.** classes that I happen to have been using a
>> lot recently. While the diff is pretty self-describing, here's
On Thu, 18 Sep 2025 17:56:35 GMT, Joe Darcy wrote:
>> Add a total that the total order used by {Double, Float}.compareTo is
>> different than the total order defined by IEEE 754, starting the 2008
>> version of that standard.
>
> Joe Darcy has updated the pull request incrementally with one add
If I saw a method called endsWithString, I'd be inclined to call
path.endsWithString(".html"), which is what started this entire thread.
Perhaps both can be added? Path.{start,end}sWithString would default to
calling toString().{start,end}sWith(arg) and Path.{start,end}sWithPath
would default
> Summary: Add two new methods to ImageReader to make SystemModuleReader more
> performant.
>
> Analysis of benchmarks shows that when the vast majority of resources
> (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in
> SystemModuleReader do NOT exist, performance is degraded com
If Path.endsWith(String) and possibly Path.startsWith(String) were to be
deprecated, then perhaps something like Path.{start,end}sWIthString(String)
could be replacements?
Brian
On Sep 18, 2025, at 11:19 AM, Rob Spoor wrote:
If Path.endsWith(String) and possibly Path.startsWith(String) are de
If Path.endsWith(String) and possibly Path.startsWith(String) are
deprecated, can we then get Path.endsWithPath(String) and
Path.startsWithPath(String) as replacements? Because having to type
path.endsWith(path.getFileSystem().getPath(other)) is not only a lot
more verbose but my IDE also compl
On Mon, 8 Sep 2025 15:45:07 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removed MBI.valueOf(double)
Thanks for yo
On Sep 17, 2025, at 8:24 AM, Pavel Rappo wrote:
FWIW, I too have fallen into this trap, and I did that even more than
once. When my brain sees Path.endsWith(String), it somehow silently
assumes that its semantic is that of String.endsWith(String).
Of course, it isn't. What's worse, I learn abou
On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote:
>> Please review this patch.
>>
>> **Description:**
>>
>> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings,
>> this may overflow and produce negative values, leading to incorrect behavior
>> in code that relies o
On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote:
> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
> from it.
+1
-
Marked as reviewed by mdoerr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239571890
> Add a total that the total order used by {Double, Float}.compareTo is
> different than the total order defined by IEEE 754, starting the 2008 version
> of that standard.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to revi
On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the
>> HTTP Client API](htt
On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the
>> HTTP Client API](htt
On Thu, 18 Sep 2025 03:31:30 GMT, Joe Darcy wrote:
> Add a total that the total order used by {Double, Float}.compareTo is
> different than the total order defined by IEEE 754, starting the 2008 version
> of that standard.
The leading words of the PR description are not in total order 😉
-
On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote:
> This PR adds a new compiler warning for `@SuppressWarnings` annotations that
> don't actually suppress any warnings.
>
> Summary of code changes:
>
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` t
On Thu, 11 Sep 2025 16:14:10 GMT, Alan Bateman wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary path check and added extra test for modules not being
>> returned.
>
> src/java.base/share/class
On Thu, 11 Sep 2025 22:36:28 GMT, Justin Lu wrote:
>> Please review this PR which is a documentation change to make apparent the
>> recommended approach for using Collator & RuleBasedCollator in a multi
>> threaded environment via an implNote. The original issue and CSR have
>> additional cont
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8357708?
>
> As noted in the issue, the current code in
> `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a
> `ServiceUnavailableException` even wh
On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote:
> When formatting doubles or BigDecimals, DigitList first formats them as a
> string and then parses the resultant string to extract the mantissa and the
> exponent. This can be done more directly. This allows removing some parsing
> code
On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early is that this is a large change, and the
On Thu, 18 Sep 2025 16:27:50 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java
>> line 30:
>>
>>> 28: /**
>>> 29: * Unchecked exception thrown when a string that is not a
>>> 30: * legal charset name is used as such.
>>
>> Could utilize
On Thu, 18 Sep 2025 16:51:47 GMT, Alan Bateman wrote:
>> OK fair enough. I just noticed that the file was modified, ie.
>>
>> // -- This file was mechanically generated: Do not edit! -- //
>>
>> was removed, so.
>
> Yes, I think that has to be removed.
Alan is right, I just copied in the gener
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote:
> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
> which removes the entire gensrc stage and instead permanently checks in the
> generated Java files.
Looks all right.
-
Marked as reviewed by
On Thu, 18 Sep 2025 16:17:24 GMT, Naoto Sato wrote:
>> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
>> which removes the entire gensrc stage and instead permanently checks in the
>> generated Java files.
>
> src/java.base/share/classes/java/nio/charset/IllegalChar
On Thu, 7 Aug 2025 21:05:13 GMT, Stuart Marks wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add @implSpec
>
> Intuitively, it feels to me like the invariant `min(a, b) == max(b, a)` would
> be useful when `a`
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote:
> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
> which removes the entire gensrc stage and instead permanently checks in the
> generated Java files.
Marked as reviewed by erikj (Reviewer).
-
On Thu, 18 Sep 2025 15:31:50 GMT, Chen Liang wrote:
>> Guanqiang Han 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 three additional
>> commits
On Wed, 17 Sep 2025 23:15:42 GMT, Brian Burkhalter wrote:
> where `Z:` is mapped as `net use Z: \\localhost\c$\Temp`, in other words to
> `C:\Temp`, a similar problem happens with `toRealPath`:
>
> ```
> jshell> Path.of("Z:\\target.txt").toRealPath()
> $7 ==> Z:\target.txt
>
> jshell> Path.of(
On Thu, 18 Sep 2025 16:32:21 GMT, Naoto Sato wrote:
>> I assume Magnus is using the generated classes and I think best to not
>> change anything else with this update. We can follow-up yesterday for
>> "opportunities" to modernize.
>
> OK fair enough. I just noticed that the file was modified,
On Thu, 18 Sep 2025 04:44:28 GMT, Chen Liang wrote:
>> Add a total that the total order used by {Double, Float}.compareTo is
>> different than the total order defined by IEEE 754, starting the 2008
>> version of that standard.
>
> src/java.base/share/classes/java/lang/Double.java line 1443:
>
+1
On 2025-09-17 03:13, wenshao wrote:
With the introduction of 8338930: StringConcatFactory hardCoded string
concatenation strategy, the StringConcatFactory#generateMHInlineCopy
method is no longer used by default.
...>
After a year of community use, the InlineHiddenClassStrategy has proven
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote:
> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
> which removes the entire gensrc stage and instead permanently checks in the
> generated Java files.
charset package changes look good to me
src/java.base
On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote:
>> Please review this patch.
>>
>> **Description:**
>>
>> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings,
>> this may overflow and produce negative values, leading to incorrect behavior
>> in code that relies o
On Wed, 17 Sep 2025 22:37:52 GMT, Justin Lu wrote:
> Please review this PR which addresses an edge case for
> `GregorianCalendar.roll(int, int)` when the rolled amount would cause the
> hour to remain the same as before the call. After this change, the expected
> hour is returned. That is, rol
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote:
> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
> which removes the entire gensrc stage and instead permanently checks in the
> generated Java files.
Can you confirm that tier1 + tier2 are passing? (most
On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote:
>> Please review this patch.
>>
>> **Description:**
>>
>> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings,
>> this may overflow and produce negative values, leading to incorrect behavior
>> in code that relies o
On Wed, 17 Sep 2025 13:32:01 GMT, Roger Riggs wrote:
>> Please review this patch.
>>
>> **Description:**
>>
>> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings,
>> this may overflow and produce negative values, leading to incorrect behavior
>> in code that relies on
On Fri, 12 Sep 2025 08:27:01 GMT, Martin Doerr wrote:
> Other idea: set count = noreg to prevent usage after it is used under the
> other name.
That wouldn't have solved the aliasing problem, because count and end were
being used as aliases for a register in _the same instruction_!
--
I agree with the removal. If we need to restore it, we can always pull it from
the git history, or just revert the removal commit.
Chen Liang
From: core-libs-dev on behalf of Claes
Redestad
Sent: Thursday, September 18, 2025 8:55 AM
To: wenshao
Cc: core-libs-d
An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
which removes the entire gensrc stage and instead permanently checks in the
generated Java files.
-
Commit messages:
- Replace tab with spaces
- 8367859: Remove nio exception gensrc
Changes: https://git.o
On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote:
> This PR adds a new compiler warning for `@SuppressWarnings` annotations that
> don't actually suppress any warnings.
>
> Summary of code changes:
>
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` t
On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote:
> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
> from it.
make/modules/java.base/Lib.gmk line 165:
> 163: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 164: LDFLAGS_aix := -brtl -bexpfull, \
> 165
Hi,
I think it was https://bugs.openjdk.org/browse/JDK-8336856 which made the old
generateMHInline non-default / opt-in.
But yes, I’ve planned proposing a removal of this for JDK 26. If you want to
file an RFE and work out a PR I’d be happy to approve, otherwise it’s on my
to-do list.
Thanks
On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion h
On Thu, 18 Sep 2025 13:13:20 GMT, Erik Joelsson wrote:
> I have started a verification job with tier1-5.
Hi Erik, thanks for checking !
-
PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307512079
On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote:
> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
> from it.
I have started a verification job with tier1-5.
-
PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307387278
On Thu, 18 Sep 2025 12:59:48 GMT, Guanqiang Han wrote:
> This safely simulates a total length exceeding Integer.MAX_VALUE and verifies
> that the change to long prevents overflow.
Can you try derive a **regression** test that fails on mainline and passes with
your fix? You can generate a strin
On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote:
> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
> from it.
Code changes look good but I guess somebody from Oracle has to verify this,
whether it does not break unwanted things.
-
Marked as rev
> Please review this patch.
>
> **Description:**
>
> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings,
> this may overflow and produce negative values, leading to incorrect behavior
> in code that relies on the UTF length. This patch changes the return type to
> long,
On 18/09/2025 08:36, Geliang Tang wrote:
I have completed the implementation. Thanks to Xiang Gao and Gang Yan
for their help. I added a new option named TCP_MPTCPIFY in
jdk.net.ExtendedSocketOptions (the name was chosen to align with
'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this op
On Thu, 11 Sep 2025 17:56:29 GMT, Joe Darcy wrote:
> Small doc enhancement to use the term "representation equivalence" in a few
> more locations.
src/java.base/share/classes/java/lang/Record.java line 132:
> 130: * Note that these rules imply that {@linkplain
> 131: * Double##repEqu
On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early is that this is a large change, and the
A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from
it.
-
Commit messages:
- JDK-8367913
Changes: https://git.openjdk.org/jdk/pull/27358/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27358&range=00
Issue: https://bugs.openjdk.org/browse/JDK-
Hi Alan,
On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote:
> Hi Alan,
>
> Thanks for your reply.
>
> On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote:
> >
> > On 05/09/2025 09:43, Geliang Tang wrote:
> >
> >
> > >
> > > :
> > >
> > > 3. Proposed Java API Changes
> > >
> > > T
93 matches
Mail list logo
