On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore
wrote:
> This PR fixes an issue that has crept into the FFM API implementation.
>
> From very early stages, the FFM API used to disable the alignment check on
> nested layout elements, in favor of an alignment check against the memory
>
On Thu, 4 Apr 2024 20:56:55 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use shorter name for the build tool
>> - Review feedback from Erik J.
>> - Remove dependency on CDS
> Proposing new overloaded methods in `java.io.Console` class that explicitly
> take a `Locale` argument. Existing methods rely on the default locale, so the
> users won't be able to format their prompts/outputs in a certain locale
> explicitly.
Naoto Sato has updated the pull request
On Wed, 8 May 2024 10:42:27 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
I don't remember it being considered, but I think it falls outside the scope of
JEP 477 (emphasis mine):
> We achieve this effect by declaring a new top-level class in the java.io
> package named, simply, IO. It declares the above three static methods for
> **textual** I/O with the console,
On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato wrote:
> In order to enlighten users to not depend on a particular version of the
> locale data, putting a note into the JDK vs. CLDR version chart would be
> appropriate.
LGTM. Wording in the beginning of the class spec makes it clear that locale
On Wed, 8 May 2024 13:13:33 GMT, Pavel Rappo wrote:
>> I haven't given it a try, but a brief look at the code suggests that if the
>> console implementation backed by JLine gets used, then a `null` prompt may
>> not generate a `NullPointerException` (since JLine appears to allow `null`)
>>
On Wed, 8 May 2024 09:39:13 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/io/Console.java line 151:
>>
>>> 149: /**
>>> 150: * Writes a string representation of the specified object to this
>>> console's
>>> 151: * output stream, terminates the line and then flushes
> This PR fixes an issue that has crept into the FFM API implementation.
>
> From very early stages, the FFM API used to disable the alignment check on
> nested layout elements, in favor of an alignment check against the memory
> segment base address. The rationale was that the JIT had issue
On Wed, 8 May 2024 15:32:27 GMT, Maurizio Cimadamore
wrote:
> * `x_handle` is really meant to provide access to a memory segment modelling
> (at least) one struct with layout `POINT_LAYOUT`. As such, the initial
> segment/offset combo should (a) be adequately aligned (according to
>
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
> [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802),
>
On Wed, 8 May 2024 17:23:25 GMT, Alan Bateman wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Extract singleton for interning BaseLocale
>
> src/java.base/share/classes/java/util/Locale.java line 1022:
>
>>
On Wed, 8 May 2024 17:57:22 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove redundant constructor
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 96:
>
>> 94: //
On Wed, 8 May 2024 16:06:29 GMT, Stuart Marks wrote:
> Most of these are defined in terms of `String.valueOf(Object)` which if
> passed a null reference will return the String object containing `null`. So
> no, I don't think NPE should be thrown. It might be worth mentioning this
> explicitly
> This PR fixes an issue that has crept into the FFM API implementation.
>
> From very early stages, the FFM API used to disable the alignment check on
> nested layout elements, in favor of an alignment check against the memory
> segment base address. The rationale was that the JIT had issue
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
> [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802),
>
On Wed, 8 May 2024 19:06:35 GMT, ExE Boss wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactor to further avoid re-validating arguments
>
>
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 18:25:50 GMT, Pavel Rappo wrote:
>> Most of these are defined in terms of `String.valueOf(Object)` which if
>> passed a null reference will return the String object containing `null`. So
>> no, I don't think NPE should be thrown. It might be worth mentioning this
>>
On Wed, 8 May 2024 20:17:18 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
In order to enlighten users to not depend on a particular version of the locale
data, putting a note into the JDK vs. CLDR version chart would be appropriate.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/19145/files
Webrev:
On Mon, 6 May 2024 23:26:49 GMT, Srinivas Vamsi Parasa wrote:
>> Hello Vamsi (@vamsi-parasa),
>>
>> Could you please run the new benchmarking to detect the best case
>> for Radix sort and parallel sorting?
>>
>> What you need is to compile and run JavaBenchmarkHarness:
>>
>> javac
On Wed, 8 May 2024 18:32:42 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove redundant constructor
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 84:
>
>> 82:
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
> [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802),
>
On Wed, 8 May 2024 17:01:05 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtained as `git merge --squash` of a now obsolete [draft
> PR].
>
>
On Wed, 8 May 2024 20:24:52 GMT, Chen Liang wrote:
> This patch allows us to merge parsing logic for invoke, constant, and
> classfile in the future, all in jdk.internal.
Thanks for reviewing! Yes, that's the idea.
-
PR Comment:
On Wed, 8 May 2024 11:36:07 GMT, serhiysachkov wrote:
>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8331646 consolidating test methods into ParameterizedTests
On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
On Wed, 8 May 2024 20:17:18 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Fri, 23 Feb 2024 14:37:20 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> VM -> virtual machine; also fix misspelling
>
> src/java.base/share/classes/java/lang/ref/Cleaner.java line 218:
>
On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan wrote:
> Clean up non-standard use of /// comments in `java.base`
Related to #19130. Good catch, these were probably not detected because they
were compiled at Java 8 language level and thus not detected by the new
compiler warnings.
-
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote:
> Tests using ProcessTools.executeProcess gets the following output written to
> stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan wrote:
> …ersion
>
> Release Note: System Property for Java SE Specification Maintenance Version
This system property should not be set for a feature release. It should only
be set if there has been a JCP Maintenance Release. Perhaps this PR
On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan wrote:
> …ersion
>
> Release Note: System Property for Java SE Specification Maintenance Version
@xiaotaonan For your information, "Release Note" issues are not bugs or
features that require a pull request, but Java Bug System tasks that serve as a
On Tue, 23 Jan 2024 08:10:54 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch introduces `JitCompiler::isConstantExpression` which can be used
> to statically determine whether an expression has been constant-folded by the
> Jit compiler, leading to more constant-folding opportunities. For
On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick wrote:
>> This provides a slightly more accurate bounding limit for
>> `computeNextExponentialSoftCapped` when calling it from
>> `computeNextGaussian`. This could cause the `while
>> (computeNextExponentialSoftCapped(rng, limit) < limit)` check
On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov wrote:
> There are 3 methods in `java.util.TimeZone` which are `public static` and
> marked as `synchronized`:
> 1. getTimeZone(String)
> 2. getAvailableIDs(int)
> 3. getAvailableIDs()
>
> This means it is a bottle neck for the whole VM.
> I've
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
On Mon, 18 Dec 2023 13:42:35 GMT, Sergey Tsypanov wrote:
> Currently if we create a record it's fields are compared in their declaration
> order. This might be ineffective in cases when two objects have "heavy"
> fields equals to each other, but different "lightweight" fields (heavy and
>
On Sun, 26 Nov 2023 16:52:40 GMT, fabioromano1 wrote:
> A faster and simpler way to generate random BigIntegers, avoiding eventually
> trimming of leading zeros in magnitude array.
This pull request has been closed without being integrated.
-
PR:
On Wed, 8 May 2024 08:33:31 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> small grammar fixes
>
> src/java.base/share/classes/java/lang/ref/Cleaner.java line 224:
>
>> 222: * Actions
Clean up non-standard use of /// comments in `java.base`
-
Commit messages:
- Clean up non-standard use of /// comments in
Changes: https://git.openjdk.org/jdk/pull/19151/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19151=00
Issue:
On Wed, 8 May 2024 19:40:44 GMT, Stuart Marks wrote:
>>> Most of these are defined in terms of `String.valueOf(Object)` which if
>>> passed a null reference will return the String object containing `null`. So
>>> no, I don't think NPE should be thrown. It might be worth mentioning this
>>>
On Thu, 9 May 2024 02:28:16 GMT, ExE Boss wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Validate after copying to avoid TOCTOU
>
> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
>
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are inflexible. It's
> either ArraysSupport.vectorizedHashCode with an
…ersion
Release Note: System Property for Java SE Specification Maintenance Version
-
Commit messages:
- Release Note: System Property for Java SE Specification Maintenance Version
Changes: https://git.openjdk.org/jdk/pull/19149/files
Webrev:
On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Wed, 8 May 2024 05:29:03 GMT, Jaikiran Pai wrote:
> Hello Raffaello, the proposed changes look OK to me. Do you think we should
> add a jtreg test for this?
>
> In general, the test coverage for these APIs appears to be missing. I think
> that can be addressed separately in some of the
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Wed, 1 May 2024 22:33:29 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Wed, 8 May 2024 05:41:52 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/18996 now allows us to test
>> Console
On Wed, 8 May 2024 05:59:14 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/18996 now allows us to test
>> Console
On Mon, 6 May 2024 19:06:10 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna
wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line
On Fri, 23 Feb 2024 06:06:21 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Wed, 8 May 2024 05:53:25 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/18996 now allows us to test
>> Console
On Wed, 8 May 2024 08:19:54 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 benchmarks.
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 benchmarks. Results in thread.
I also removed the BigDecimal.toString benchmarks.
On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti
wrote:
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
This pull request has now been integrated.
Changeset:
On Tue, 7 May 2024 16:43:11 GMT, Naoto Sato wrote:
> Sorry if I was unclear, but I meant to consolidate the test methods, as they
> are duplicates other than the calendar values. Those values should be
> parametrized and consolidate the test body into a single method.
sorry for
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
> Calendar.add() tests that describe its behavior.
serhiysachkov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8331646 consolidating test methods into ParameterizedTests
-
Changes:
- all:
On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Marked as reviewed by mgronlun
On Wed, 8 May 2024 08:59:18 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/io/Console.java line 192:
>>
>>> 190: *
>>> 191: * @param prompt
>>> 192: * A prompt string.
>>
>> Hello Pavel, should this specify whether `prompt` can be null?
>
> If we specify
A rather large startup regression was introduced in 23-b13 from
[JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
been dealt with as enhancements such as
[JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802),
On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 8 May 2024 14:53:05 GMT, Claes Redestad wrote:
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
>
On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai wrote:
>> If we specify that, it would be very much unlike all other `Console` methods
>> that are covered by this:
>>
>> * Unless otherwise specified, passing a {@code null} argument to any
>> method
>> * in this class will cause a {@link
Has it been considered to add a readKey() method to IO class? In my
experience, it is pretty commonly used by beginners when they write things
like console games (snake, catcher game etc.). I am aware there is
System.in.read() method, but since we decided to promote some methods to
separate
82 matches
Mail list logo
