On Mon, 6 May 2024 21:45:12 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 merge
On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang wrote:
> As discussed on the mailing list
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html,
> BufWriter::asByteBuffer has a behavior not suitable for API and is only used
> by internal StackMapGenerator/StackCounter, so
On Tue, 27 Feb 2024 15:10:37 GMT, Nizar Benalla wrote:
> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were
> made to the method signatures but this modification isn't reflected in the @
> since tags. The @ since tags need to be updated.
>
> I changed the
On Tue, 7 May 2024 01:26:30 GMT, Chen Liang wrote:
> Should this be final?
With only the private constructor, it doesn't matter too much in practice, but
an explicit `final` would be good documentation if that is the intent.
-
PR Review Comment:
On Mon, 6 May 2024 22:00:24 GMT, Claes Redestad wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to
> throw IAE and
On Mon, 6 May 2024 21:45:12 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 merge
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to
> throw IAE and
On Tue, 30 Apr 2024 22:01:30 GMT, Vladimir Yaroslavskiy
wrote:
>> Hi Vladimir (@iaroslavski),
>>
>> Please see the data below:
>>
>> Thanks,
>> Vamsi
>>
>>
>>
>> name | builder | size | mode | count | score
>> -- | -- | -- | -- | -- | --
>> b01 | RANDOM | 600 | avg | 325677 | 6.862
>> b01
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
> thrpt3 6443.934 ± 6.491 ops/s
>
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
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].
[Implicitly Declared
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
A peek into TypeKind during the research for #19105 reveals that TypeKind has a
few issues:
1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use
"newarray code"
2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to
throw IAE and added tests.
3.
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
> 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 with a
On Mon, 6 May 2024 18:55:25 GMT, Justin Lu wrote:
>> Please review this PR which corrects an edge case bug for
>> java.text.DecimalFormat that causes incorrect parsing results for strings
>> with very large exponent values.
>>
>> When parsing values with large exponents, if the value of the
On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote:
>> This PR outlines a solution for making immutable maps `@ValueBased` by
>> removing cacheing of certain values in `AbstractMap`.
>>
>> By removing these caching fields in `AbstractMap`, we can make the immutable
>> maps `@ValueBased` and
> 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 issue linked above,
>
On Thu, 2 May 2024 10:30:06 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
> Please review this PR which corrects an edge case bug for
> java.text.DecimalFormat that causes incorrect parsing results for strings
> with very large exponent values.
>
> When parsing values with large exponents, if the value of the exponent
> exceeds `Integer.MAX_VALUE`, the parsed value
On Mon, 6 May 2024 16:59:40 GMT, Naoto Sato wrote:
> For the latter, since you are already at it, I just reassigned the bug to you
>
@lahodaj, since a test for 8331681 is added to this PR, I'd suggest you do
this: `/issue add 8331681`.
-
PR Review Comment:
On Mon, 6 May 2024 18:07:06 GMT, Vicente Romero wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed tests
>
> src/java.base/share/classes/java/lang/classfile/Attributes.java line 28:
>
>> 26:
>> 27: import
On Mon, 6 May 2024 16:30:11 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
On Mon, 6 May 2024 17:52:07 GMT, Justin Lu wrote:
>> Please review this PR which corrects an edge case bug for
>> java.text.DecimalFormat that causes incorrect parsing results for strings
>> with very large exponent values.
>>
>> When parsing values with large exponents, if the value of the
On Mon, 6 May 2024 16:07:26 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov wrote:
> Calendar.add() tests that describe its behavior.
I would prefer those test values are parametrized.
-
PR Review: https://git.openjdk.org/jdk/pull/19082#pullrequestreview-2041403213
> Hi,
> During performance optimization work on Class-File API as JDK lambda
> generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields
> initialized with individual attribute mappers, and common set of all mappers,
>
This PR is to implement the `nonlikelyScript` feature that went into CLDR
version 45 for migration purposes. In its release note, it states
(https://cldr.unicode.org/index/downloads/cldr-45):
Migration
Changes to parentLocales require upgrading implementations that use that
element. In
On Sun, 5 May 2024 20:51:10 GMT, Axel Hauschulte wrote:
>> Justin Lu has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - correct other test comment
>> - reflect review
>
> Hello, I filed
> Please review this PR which corrects an edge case bug for
> java.text.DecimalFormat that causes incorrect parsing results for strings
> with very large exponent values.
>
> When parsing values with large exponents, if the value of the exponent
> exceeds `Integer.MAX_VALUE`, the parsed value
While `@since` might not be considered a normative part of the
specification, (it's effectively a cache of derived meta-data) it is
part of the generated documentation, and as such deserves to be correct.
-- Jon
On 5/5/24 4:33 PM, Pavel Rappo wrote:
On Mon, 29 Apr 2024 17:46:24 GMT, Nizar
On Mon, 6 May 2024 16:09:19 GMT, Jan Lahoda wrote:
>> When JLine reads a line, there may be a prompt provided. However, JLine will
>> not interpret the prompt literally, it will handle `%` specially. As a
>> consequence, doing:
>>
>> System.console().readLine("%%s");
>>
>>
>> will not print
On Mon, 6 May 2024 16:05:58 GMT, Jan Lahoda wrote:
>>> We have a test that checks if `System.console()` returns the correct
>>> Console (or null) from the expected module
>>> (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>>>
>>
>> Good; then here we should indeed specify
On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov wrote:
> Calendar.add() tests that describe its behavior.
The bug report and/or the PR description should describe the change in more
detail.
What conditions of the Calendar spec are being tested. Thanks
-
PR Comment:
On Mon, 6 May 2024 16:30:11 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
> 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 issue linked above,
>
On Mon, 6 May 2024 10:21:12 GMT, Jaikiran Pai wrote:
>> Hi @mlchung, thanks for the feedback! I’ve pushed the updates.
>>
>> Just a question about ```NULL_CHECK0```.
>>
>> ```NULL_CHECK0``` reports the error message and then the exception is
>> described in ```CHECK_EXCEPTION_LEAVE```. This
> When JLine reads a line, there may be a prompt provided. However, JLine will
> not interpret the prompt literally, it will handle `%` specially. As a
> consequence, doing:
>
> System.console().readLine("%%s");
>
>
> will not print `%s`, as first `String.format` is used, which will convert
On Fri, 3 May 2024 21:59:40 GMT, Pavel Rappo wrote:
>>> Ideally, we should have separate tests that make sure that jdk.internal.le
>>> is the default impl.
>>
>> We have a test that checks if `System.console()` returns the correct Console
>> (or null) from the expected module
>>
> Hi,
> During performance optimization work on Class-File API as JDK lambda
> generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields
> initialized with individual attribute mappers, and common set of all mappers,
>
On Mon, 6 May 2024 11:16:16 GMT, Claes Redestad wrote:
> FWIW code changes looks good to me. There seems to be a number of tests that
> still need to be updated to use the new methods instead of the old constants.
Thank you!
Yes, I'm cleaning the tests right now.
-
PR Comment:
On Thu, 2 May 2024 14:40:16 GMT, Chen Liang wrote:
> On a side note, will we update JEP 466 to include this patch?
I hope so, if we get it into 23 ;)
-
PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2096378934
> Hi,
> During performance optimization work on Class-File API as JDK lambda
> generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields
> initialized with individual attribute mappers, and common set of all mappers,
>
On Fri, 3 May 2024 11:20:52 GMT, Pavel Rappo wrote:
>> Jan Lahoda 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.
>
>
On Mon, 6 May 2024 15:15:36 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
Calendar.add() tests that describe its behavior.
-
Commit messages:
- Merge remote-tracking branch 'origin/JDK-8331646' into JDK-8331646
- JDK-8331646 adding tests to validate Calendar.add() for leap year
- JDK-8331646 Add specific regression leap year tests
Changes:
On Mon, 6 May 2024 15:20:08 GMT, Nizar Benalla wrote:
>> Please review this PR that aims to add all the remaining needed `@since`
>> tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are
On Mon, 6 May 2024 14:58:02 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename ofTrusted to ofValidated, remove accidental module-info exports
>
>
> Please review this PR that aims to add all the remaining needed `@since` tags
> in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose
> of
On Wed, 17 Apr 2024 09:20:24 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> public class MainClass {
>> public MainClass() {
>> System.out.println("Constructor called!");
>> }
>> public static void main() {
>> System.out.println("main called!");
>> }
>> }
>>
On Fri, 12 Apr 2024 10:16:36 GMT, Jan Lahoda wrote:
> Consider code like:
>
> public class MainClass {
> public MainClass() {
> System.out.println("Constructor called!");
> }
> public static void main() {
> System.out.println("main called!");
> }
> }
>
> and
> 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
On Mon, 6 May 2024 15:03:53 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java
>> line 68:
>>
>>> 66: * @jvms 4.3.2 Field Descriptors
>>> 67: */
>>> 68: public static ReferenceClassDescImpl ofTrusted(String descriptor) {
>>
> 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
On Mon, 6 May 2024 14:51:17 GMT, Chen Liang 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 Mon, 6 May 2024 14:46:09 GMT, Chen Liang 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 Mon, 6 May 2024 14:39:08 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 some
> Hi,
> During performance optimization work on Class-File API as JDK lambda
> generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields
> initialized with individual attribute mappers, and common set of all mappers,
>
On Thu, 2 May 2024 11:08:16 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Tue, 23 Apr 2024 18:21:30 GMT, Sonia Zaldana Calles
wrote:
>>> Just to clarify, this would still mean converting “isStatic” and “noArgs”
>>> from local variables to fields so I am able to read them on the C side of
>>> things. Did I understand this correctly?
>>
>> I'm okay with adding
On Mon, 6 May 2024 08:28:50 GMT, Jan Lahoda wrote:
> When integrating:
> https://github.com/openjdk/jdk/pull/18996
>
> I've forgot to push one last commit which was stabilizing the test of Mac
> OS/X. I am sorry for that.
>
> The test will create a pseudo terminal, and change the current
On Mon, 6 May 2024 08:28:50 GMT, Jan Lahoda wrote:
> When integrating:
> https://github.com/openjdk/jdk/pull/18996
>
> I've forgot to push one last commit which was stabilizing the test of Mac
> OS/X. I am sorry for that.
>
> The test will create a pseudo terminal, and change the current
When integrating:
https://github.com/openjdk/jdk/pull/18996
I've forgot to push one last commit which was stabilizing the test of Mac OS/X.
I am sorry for that.
The test will create a pseudo terminal, and change the current process
stdin/stdout to write into the pty. But, there's nothing
On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla wrote:
> Please review this PR that aims to add all the remaining needed `@since` tags
> in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are
> When JLine reads a line, there may be a prompt provided. However, JLine will
> not interpret the prompt literally, it will handle `%` specially. As a
> consequence, doing:
>
> System.console().readLine("%%s");
>
>
> will not print `%s`, as first `String.format` is used, which will convert
On Mon, 29 Apr 2024 11:44:50 GMT, Jan Lahoda wrote:
> Consider code like:
>
> public class ConsoleTest {
> public static void main(String... args) {
> System.console().printf("Hello!");
> }
> }
>
>
> When run as:
>
> $ java ConsoleTest.java >/dev/null
>
>
> it prints
70 matches
Mail list logo
