Re: RFR: 8305762: FileInputStream and FileOutputStream implSpec should be corrected or removed

On Tue, 11 Apr 2023 23:55:50 GMT, Brent Christian wrote: > With the removal of the AltFinalizer mechanism from `FileInputStream` and > `FileOutputStream` in > [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of > the Implementation Requirement in the class JavaDoc is

Re: RFR: 8296248: Update CLDR to Version 43.0 [v2]

> Upgrading the CLDR to [version > 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual > release is their `limited-submission` release so I would not expect > regressions caused by formatting changes as we had in JDK20/CLDRv42 >

Re: RFR: 8266571: Sequenced Collections [v5]

> PR for Sequenced Collections implementation. Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: - Merge branch 'master' into JDK-8266571-SequencedCollections - Simplify handling of cached keySet, values, and

Re: RFR: 8296248: Update CLDR to Version 43.0

On Thu, 13 Apr 2023 20:46:10 GMT, Steven R. Loomis wrote: >> Upgrading the CLDR to [version >> 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual >> release is their `limited-submission` release so I would not expect >> regressions caused by formatting changes as we had

Re: RFR: 8296248: Update CLDR to Version 43.0

On Thu, 13 Apr 2023 20:47:39 GMT, Steven R. Loomis wrote: >> Upgrading the CLDR to [version >> 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual >> release is their `limited-submission` release so I would not expect >> regressions caused by formatting changes as we had

Re: RFR: 8296248: Update CLDR to Version 43.0

On Thu, 13 Apr 2023 20:20:02 GMT, Naoto Sato wrote: > Upgrading the CLDR to [version > 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual > release is their `limited-submission` release so I would not expect > regressions caused by formatting changes as we had in

RFR: 8296248: Update CLDR to Version 43.0

Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v62]

On Thu, 13 Apr 2023 19:45:59 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v62]

> Enhance the Java programming language with string templates, which are > similar to string literals but contain embedded expressions. A string > template is interpreted at run time by replacing each expression with the > result of evaluating that expression, possibly after further validation

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Thu, 13 Apr 2023 15:27:12 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 75 commits: >> >> - Merge branch 'master' into 8285932 >> - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable. >>

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v61]

On Thu, 13 Apr 2023 14:30:19 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Typo > > src/jdk.incubator.concurrent/share/classes/module-info.java line 35: > >> 33: exports

Re: RFR: 8305904: java/lang/Character, java/lang/String and java/text/Normalizer tests read the unicode data files from src directories.

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa wrote: > Following tests read the unicode data files > (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, > these files should be in test directories. No source code is using these > files. Only tests are using these

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v61]

On Thu, 13 Apr 2023 17:09:13 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

The core problem of these two methods is that they should have clear semantics (locale sensitive), but due to a large number of misuses, they cannot express the user's intention. The only point in making their behavior configurable is that for buggy legacy code we can modify the configuration to

Re: RFR: 8305904: java/lang/Character, java/lang/String and java/text/Normalizer tests read the unicode data files from src directories.

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa wrote: > Following tests read the unicode data files > (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, > these files should be in test directories. No source code is using these > files. Only tests are using these

Re: RFR: 8305904: java/lang/Character, java/lang/String and java/text/Normalizer tests read the unicode data files from src directories.

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa wrote: > Following tests read the unicode data files > (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, > these files should be in test directories. No source code is using these > files. Only tests are using these

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v61]

> Enhance the Java programming language with string templates, which are > similar to string literals but contain embedded expressions. A string > template is interpreted at run time by replacing each expression with the > result of evaluating that expression, possibly after further validation

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v59]

On Thu, 13 Apr 2023 16:38:25 GMT, Daniel Fuchs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove preview feature on package private java.util.Digits > >

Integrated: 8305875: Test TraceVirtualThreadLocals should be run with continuations only

On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik wrote: > Test TraceVirtualThreadLocals verifies that thread locals are dumped for > virtual threads. It fails when continuations are not available and virtual > threads are emulated. > > The test failed on linux-x86 so I just want to mark it to

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v59]

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v59]

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v60]

> Enhance the Java programming language with string templates, which are > similar to string literals but contain embedded expressions. A string > template is interpreted at run time by replacing each expression with the > result of evaluating that expression, possibly after further validation

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v59]

On Thu, 13 Apr 2023 16:27:51 GMT, Daniel Fuchs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove preview feature on package private java.util.Digits > > src/java.base/share/classes/java/util/Digits.java line

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

> > Another possibility to mitigate the situation rather than introducing > the new methods is to introduce a new system property and let the users > decide the default (yes, yet another property, but I believe it > warrants). Say, > I think this can only be used as a transitional solution, and

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

I too agree with Roger that deprecation would have high bar. Another possibility to mitigate the situation rather than introducing the new methods is to introduce a new system property and let the users decide the default (yes, yet another property, but I believe it warrants). Say,

Re: RFE: SequenceInputStream - Consider new issue for PR #11718

Voila: https://bugs.openjdk.org/browse/JDK-8305947 On Apr 11, 2023, at 9:06 AM, Brian Burkhalter mailto:brian.burkhal...@oracle.com>> wrote: Hello, You should be able to file an issue yourself at https://bugreport.java.com/bugreport/start_form Brian On Apr 10, 2023, at 11:59 PM, Benjamin

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

> > In that case, isn't there something a little backwards about saying we > should continue sweeping them under the rug? (Am I being too idealistic?) > I sympathise with the concern of causing many warnings/errors, and the right time to do these things never seems to be "now". But let's look at

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

On Thu, Apr 13, 2023 at 9:14 AM Roger Riggs wrote: > And yes, it is a problem to cause many warnings; it creates an immediate > and pressing need for projects that have tight source requirements and > don't allow warnings, for example, the JDK itself. > Hmm.. I'd agree with this statement if

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

> In my experience, it will take longer to agree on the deprecation than adding a simple API with known semantics. All right, so I'll focus on creating new APIs first. I hope to get it at least in Java 21. It is also acceptable to deprecate the old API at a later date. As observed, coming to

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

Hi, In my experience, it will take longer to agree on the deprecation than adding a simple API with known semantics. An important element of the deprecation messaging is the potential replacement. Having the replacement in hand gives a clear message and action that can be scripted. IDE's

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Thu, 13 Apr 2023 13:29:33 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 75 commits: >> >> - Merge branch 'master' into 8285932 >> - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable. >>

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v59]

> Enhance the Java programming language with string templates, which are > similar to string literals but contain embedded expressions. A string > template is interpreted at run time by replacing each expression with the > result of evaluating that expression, possibly after further validation

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v58]

> Enhance the Java programming language with string templates, which are > similar to string literals but contain embedded expressions. A string > template is interpreted at run time by replacing each expression with the > result of evaluating that expression, possibly after further validation

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Thu, 13 Apr 2023 07:42:24 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 75 commits: >> >> - Merge branch 'master' into 8285932 >> - Change MAX_INDY_CONCAT_ARG_SLOTS to be

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Wed, 12 Apr 2023 20:50:35 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 75 commits: >> >> - Merge branch 'master' into 8285932 >> - Change MAX_INDY_CONCAT_ARG_SLOTS to be

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v56]

On Wed, 12 Apr 2023 15:15:09 GMT, Chen Liang wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable. > >

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v56]

On Wed, 12 Apr 2023 15:09:50 GMT, Chen Liang wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable. > > src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java

Re: RFR: 8205129: Remove java.lang.Compiler

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos wrote: > Please help review this PR which suggests we remove the class > `java.lang.Compiler`. The class seems non-functional for a decade, and was > terminally deprecated in Java 9. Time has come to let it go. The Release Note for this PR did

Re: Question: Review process of release notes

> > > Unless your reviewers indicate they have seen the Release Note I would > not assume that. If unclear ask someone to add a comment to the JBS > issue saying they think it is okay. > This was very useful. Thank, Eirik.

Re: Question: Review process of release notes

On 13/04/2023 5:20 pm, Eirik Bjørsnøs wrote: https://openjdk.org/guide/#release-notes Thanks David, I just found this and it seems to answer most of my questions. It does not explicitly say that the release note is considered approved when

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: RFD: Notes in String.toUpperCase(), String.toLowerCase() could be more specific refering to "locale"

> > Any thoughts? > I'll add my own thoughts, which is that busy developers cannot be expected to do the "right thing" if they don't understand the API Note. Improving the note such that more developers understand the consequences of using the method should help developers write more correct

RFD: Notes in String.toUpperCase(), String.toLowerCase() could be more specific refering to "locale"

Hello, During a discussion about the deprecation of String.toLowerCase(), String.toUpperCase [1], it occurred to me that the current Note in the API documentation could be more specific when talking about locales. Before going ahead and suggesting a PR/CSR, I'd like to socialize the idea that we

Re: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v57]

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

> > Deprecating the existing methods would cause lots of warnings and > provide little actual improvement. > I don't think there is only little actual improvement. **Almost all** use cases of these two methods are misuse. Even the correct use of them is not recommended, as there are too many

Re: Question: Review process of release notes

> > https://openjdk.org/guide/#release-notes Thanks David, I just found this and it seems to answer most of my questions. It does not explicitly say that the release note is considered approved when the PR is approved, but I guess I'm safe to assume so. Cheers, Eirik.

Re: Question: Review process of release notes

Hi Eirik, https://openjdk.org/guide/#release-notes HTH David On 13/04/2023 4:40 pm, Eirik Bjørsnøs wrote: Hi, My understanding of the review process for release notes is a bit sketchy, I could need some clarification. Consider my release note for JDK-8205129 Remove java.lang.Compiler as

Integrated: 8304450: [vectorapi] Refactor VectorShuffle implementation

On Sun, 19 Mar 2023 13:04:19 GMT, Quan Anh Mai wrote: > Hi, > > This patch reimplements `VectorShuffle` implementations to be a vector of the > bit type. Currently, VectorShuffle is stored as a byte array, and would be > expanded upon usage. This poses several drawbacks: > > 1. Inefficient

Question: Review process of release notes

Hi, My understanding of the review process for release notes is a bit sketchy, I could need some clarification. Consider my release note for JDK-8205129 Remove java.lang.Compiler as an example: https://bugs.openjdk.org/browse/JDK-8304459 The PR is approved and integrated and the issue Resolved

Re: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) [v23]

> API changes for the FFM API (third preview) > > ### Specdiff > https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html > > ### Javadoc > https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html > > ### Tests > > - [X] Tier1 > - [X] Tier2 > - [