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

[Kim Barrett]

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 no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been 
>> overridden, the close() method will be called when the FileInputStream is 
>> unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect 
> current behavior, and guidance for subclasses is clarified.

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1384600764

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

[Naoto Sato]

> 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/)

Naoto Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Short ID test for "America/Ciudad_Juarez"

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/13469/files
  - new: https://git.openjdk.org/jdk/pull/13469/files/d61ccf0f..7211ffd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=13469=01
 - incr: https://webrevs.openjdk.org/?repo=jdk=13469=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13469/head:pull/13469

PR: https://git.openjdk.org/jdk/pull/13469

Re: RFR: 8266571: Sequenced Collections [v5]

[Stuart Marks]

> 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 entrySet views.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Update copyrights.
 - More specification tweaks.
 - Add simple overrides to ArrayList.
 - Specification cleanups.
 - Update spec of CopyOnWriteArrayList::reversed.
 - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing 
it publicly.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
   Resolve conflict by deleting IdentityLinkedList.java
 - ... and 70 more: https://git.openjdk.org/jdk/compare/76cda9f4...1332c3e2

-

Changes: https://git.openjdk.org/jdk/pull/7387/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=7387=04
  Stats: 6644 lines in 39 files changed: 6509 ins; 11 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

Re: RFR: 8296248: Update CLDR to Version 43.0

[Naoto Sato]

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 in JDK20/CLDRv42 
>> (https://inside.java/2023/03/28/quality-heads-up/)
>
> make/data/cldr/common/main/ken.xml line 19:
> 
>> 17:  
>> 18:  
>> 19:  [a á à ǎ b c d e é è ě ɛ {ɛ\u0301} 
>> {ɛ\u0300} {ɛ\u030C} f g {gb} {gh} h i ɨ {ɨ\u0301} {ɨ\u0300} {ɨ\u030C} j k 
>> {kp} m n {ny} ŋ o ó ò ǒ ɔ {ɔ\u0301} {ɔ\u0300} {ɔ\u030C} p r s t u ú ù ǔ ʉ 
>> {ʉ\u0301} {ʉ\u0300} {ʉ\u030C} w y]
> 
> @naotoj  this is in common/main but not at basic level… is this intentional?

JDK keeps CLDR sources intact. On building JDK, .xml files are transformed into 
ResourceBundles and those not at the basic level are filtered out.

> make/data/cldr/common/properties/coverageLevels.txt line 115:
> 
>> 113: sq ;modern ;Albanian
>> 114: sr ;modern ;Serbian
>> 115: sr_Latn ;   modern ;Serbian (Latin)
> 
> @naotoj BTW this was fixed

Yes. The patch before was removed with this commit: 
https://github.com/openjdk/jdk/pull/13469/commits/0e3456c8924960dc0bc488b08b9763bd08557a68

-

PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055276
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055288

Re: RFR: 8296248: Update CLDR to Version 43.0

[Steven R . Loomis]

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 in JDK20/CLDRv42 
>> (https://inside.java/2023/03/28/quality-heads-up/)
>
> Marked as reviewed by srl...@github.com (no known OpenJDK username).

`@srl295 (no known openjdk.org user name / role)` 

-

PR Comment: https://git.openjdk.org/jdk/pull/13469#issuecomment-1507597408

Re: RFR: 8296248: Update CLDR to Version 43.0

[Steven R . Loomis]

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 JDK20/CLDRv42 
> (https://inside.java/2023/03/28/quality-heads-up/)

Marked as reviewed by srl...@github.com (no known OpenJDK username).

make/data/cldr/common/main/ken.xml line 19:

> 17:   
> 18:   
> 19:   [a á à ǎ b c d e é è ě ɛ {ɛ\u0301} 
> {ɛ\u0300} {ɛ\u030C} f g {gb} {gh} h i ɨ {ɨ\u0301} {ɨ\u0300} {ɨ\u030C} j k 
> {kp} m n {ny} ŋ o ó ò ǒ ɔ {ɔ\u0301} {ɔ\u0300} {ɔ\u030C} p r s t u ú ù ǔ ʉ 
> {ʉ\u0301} {ʉ\u0300} {ʉ\u030C} w y]

@naotoj  this is in common/main but not at basic level… is this intentional?

make/data/cldr/common/properties/coverageLevels.txt line 115:

> 113: sq ; modern ;Albanian
> 114: sr ; modern ;Serbian
> 115: sr_Latn ;modern ;Serbian (Latin)

@naotoj BTW this was fixed

src/java.base/share/legal/cldr.md line 1:

> 1: ## Unicode Common Local Data Repository (CLDR) v43

BTW the license is now just named `LICENSE` in the repo starting with v44

-

PR Review: https://git.openjdk.org/jdk/pull/13469#pullrequestreview-1384183612
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009340
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009761
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166010264

RFR: 8296248: Update CLDR to Version 43.0

[Naoto Sato]

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/)

-

Commit messages:
 - v42 -> v43 in README, .md files
 - release-43
 - Removed sr-Latn (https://unicode-org.atlassian.net/browse/CLDR-16449)
 - release-43-beta5
 - release-43-beta4
 - release-43-beta3
 - release-43-beta1
 - release-43-beta0
 - Fixing IncludeLocalesPluginTest.java not to include below `basic` locales
 - release-43-alpha2
 - ... and 5 more: https://git.openjdk.org/jdk/compare/92521b10...d61ccf0f

Changes: https://git.openjdk.org/jdk/pull/13469/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=13469=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296248
  Stats: 209680 lines in 1036 files changed: 199351 ins; 2906 del; 7423 mod
  Patch: https://git.openjdk.org/jdk/pull/13469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13469/head:pull/13469

PR: https://git.openjdk.org/jdk/pull/13469

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

[Roger Riggs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from 
> non-public classes

Core library files look good to me.

-

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1384156858

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

[Jim Laskey]

> 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 and 
> transformation. This is a [preview language feature and 
> API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from 
non-public classes

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f27ad709..70c215c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=10889=61
 - incr: https://webrevs.openjdk.org/?repo=jdk=10889=60-61

  Stats: 54 lines in 10 files changed: 30 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

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

[Jim Laskey]

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.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a 
>> lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:
> 
>> 552: 
>> 553: /**
>> 554:  * Class used to tally ahd track the number of ints, longs and 
>> objects.
> 
> typo: ahd

Will fix.

> src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:
> 
>> 35:  * @since 21
>> 36:  */
>> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> Generally, The `PreviewFeature` annotation is not needed on internal APIs and 
> serves little purpose.

PreviewFeature might be heavy handed. I can replace it with a warning to not 
depend on this file.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915844
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915665

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

[Jim Laskey]

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 jdk.incubator.concurrent;
>> 34: }
>> 35: 
> 
> Not related to StringTemplates; could be left as is.

Agree - I think it must have been a merge issue. I don't recall having a need 
to change this file.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165914905

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

[Naoto Sato]

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 files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Missed that the intended change is not duplicating but moving from src->test. 
No this is not correct.

-

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507411392

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

[Roger Riggs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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 jdk.incubator.concurrent;
> 34: }
> 35: 

Not related to StringTemplates; could be left as is.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165615588

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

[Roger Riggs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a 
> lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

The PreviewFeature annotations can/should be removed from classes/methods that 
are not part of the public interface. They are unnecessary and possibly 
misleading, implying part of the public interface.

src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:

> 552: 
> 553: /**
> 554:  * Class used to tally ahd track the number of ints, longs and 
> objects.

typo: ahd

src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:

> 35:  * @since 21
> 36:  */
> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

Generally, The `PreviewFeature` annotation is not needed on internal APIs and 
serves little purpose.

-

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1383555414
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165702256
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165631226

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

[Glavo]

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 make it behave correctly. It is not
helpful for
developers who are writing new code, as developers understand in almost
always aware
of whether they need locale sensitivity, so using this vague methods
actually masks
their intentions.

Our only way to make these methods with huge historical burdens usable is
to
change and fix their behavior to be locale insensitive. But this is a
breaking
change and will cause trouble for users who use the new version of JDK but
target the old version of JRE.

In summary, we cannot satisfy users with them, so we can only give them up
and
let all users no longer use them in new code.


Another issue is that we can use
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
to achieve the expected behavior, so why do we need to introduce a new API?

For this issue, we need to take a look at the current way.

Firstly, it is lengthy, so users may feel impatient with it.

This lengthy way not only lacks clarity, but also reduces readability.
It forces the user to use Locale when it is not locale sensitive, which
generates
noise, and also makes it harder for the user to find which parts of the
code are
locale sensitive.

This is why I want to introduce new APIs.


---

These are the steps I believe are reasonable to address these issues:

1. Add new locale insensitive APIs and recommend users to use them in new
code.

   I hope this step can be implemented in Java 21.

2. Add a new system property that allows users to configure the behavior of
   these two methods.

3. Gradually clean up the use cases inside JDK.

   Since this involves a dozen modules and hundreds of source files, I need
to
   split them into many PRs, and some of them require CSR. Reviewing them
may
   take a long time, this step will be done slowly in the future.

4. Deprecate the two methods.

   This step may take place much later.

This is my idea, and I hope to receive your opinion.

Glavo

On Fri, Apr 14, 2023 at 12:08 AM Naoto Sato  wrote:

> 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,
>
> java.lang.String.defaultCaseLocale=[root/display/format]
>
> where each value designates
>
> root -> Locale.ROOT
> display -> Locale.getDefault(Locale.Category.DISPLAY)
> format -> Locale.getDefault(Locale.Category.FORMAT)
>
> The choice for the "default" default have room to discuss, but format
> may not be bad choice.
>
> As to the current spec, we can emphasize the Turkish issue more visible
> by making "Notes:" to @apiNote.
>
> Naoto
>
> On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:
> > 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 it this way: The Turkish population alone is
> > currently 1.08 percent of the world population. If we assume the number
> > of Java apps/services per capita is the same around the world, this
> > means that these methods may return the expected result in 98.92 percent
> > of the executions. I think that's a bit scary.
> >
> > Deprecating these methods would require consensus and support from
> > reviewers, which we don't seem to have at the moment. So I think the
> > current focus on fixing the uses inside OpenJDK and then adding
> > alternatives first seems good. Then, maybe someday.. :-)
> >
> > Eirik.
>

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

[Roger Riggs]

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 files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Are you aware of the uses in the makefiles?  

make/modules/java.base/Gendata.gmk
make/modules/java.base/gendata/GendataBreakIterator.gmk
make/modules/java.base/gensrc/GensrcCharacterData.gmk

-

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507386116

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

[Naoto Sato]

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 files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Hi Mahendra,

What's the point of having the Unicode data files duplicate? That would cause a 
possible mismatch between the files between src and test.

-

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507365030

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

[Jim Laskey]

> 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 and 
> transformation. This is a [preview language feature and 
> API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional 
commit since the last revision:

  Typo

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/961a5417..f27ad709

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=10889=60
 - incr: https://webrevs.openjdk.org/?repo=jdk=10889=59-60

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

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

[Jim Laskey]

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
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 167:
> 
>> 165:  * {@link FormatProcessor#process(StringTemplate)}. This {@link 
>> MethodHandle}
>> 166:  * is used by {@link FormatProcessor#FMT} and the ilk to perform a 
>> more
>> 167:  * specialized composition of a result. This is specialization is 
>> done by
> 
> Typo here? "This is specialization is done"

removing "is"

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165799277

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

[Leonid Mesnik]

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 have green github 
> actions results.

This pull request has now been integrated.

Changeset: 92521b10
Author:Leonid Mesnik 
URL:   
https://git.openjdk.org/jdk/commit/92521b100f1eb785eabd101870f631f555c3b135
Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod

8305875: Test TraceVirtualThreadLocals should be run with continuations only

Reviewed-by: alanb

-

PR: https://git.openjdk.org/jdk/pull/13436

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

[Daniel Fuchs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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/FormatProcessor.java line 167:

> 165:  * {@link FormatProcessor#process(StringTemplate)}. This {@link 
> MethodHandle}
> 166:  * is used by {@link FormatProcessor#FMT} and the ilk to perform a 
> more
> 167:  * specialized composition of a result. This is specialization is 
> done by

Typo here? "This is specialization is done"

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165785237

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

[Daniel Fuchs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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 233:

> 231: 
> 232: /**
> 233:  * Singleton instance of HexDigits.

Suggestion:

 * Singleton instance of OctalDigits.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165774156

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

[Jim Laskey]

> 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 and 
> transformation. This is a [preview language feature and 
> API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional 
commit since the last revision:

  HexDigits -> OctalDigits

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/69f49bdf..961a5417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=10889=59
 - incr: https://webrevs.openjdk.org/?repo=jdk=10889=58-59

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

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

[Jim Laskey]

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 233:
> 
>> 231: 
>> 232: /**
>> 233:  * Singleton instance of HexDigits.
> 
> Suggestion:
> 
>  * Singleton instance of OctalDigits.

Nice catch

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165778236

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

[Glavo]

>
> 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 it doesn't
really
solve the problem - the semantics of toLowerCase()/toUpperCase() are still
vague,
so toLowerCase(Locale)/toUpperCase(Locale) is still needed to get
deterministic
behavior.

I agree that this solution can be used instead of deprecating these two
APIs,
but I think the new APIs are still necessary.

Glavo

On Fri, Apr 14, 2023 at 12:08 AM Naoto Sato  wrote:

> 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,
>
> java.lang.String.defaultCaseLocale=[root/display/format]
>
> where each value designates
>
> root -> Locale.ROOT
> display -> Locale.getDefault(Locale.Category.DISPLAY)
> format -> Locale.getDefault(Locale.Category.FORMAT)
>
> The choice for the "default" default have room to discuss, but format
> may not be bad choice.
>
> As to the current spec, we can emphasize the Turkish issue more visible
> by making "Notes:" to @apiNote.
>
> Naoto
>
> On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:
> > 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 it this way: The Turkish population alone is
> > currently 1.08 percent of the world population. If we assume the number
> > of Java apps/services per capita is the same around the world, this
> > means that these methods may return the expected result in 98.92 percent
> > of the executions. I think that's a bit scary.
> >
> > Deprecating these methods would require consensus and support from
> > reviewers, which we don't seem to have at the moment. So I think the
> > current focus on fixing the uses inside OpenJDK and then adding
> > alternatives first seems good. Then, maybe someday.. :-)
> >
> > Eirik.
>

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

[Naoto Sato]

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,


java.lang.String.defaultCaseLocale=[root/display/format]

where each value designates

root -> Locale.ROOT
display -> Locale.getDefault(Locale.Category.DISPLAY)
format -> Locale.getDefault(Locale.Category.FORMAT)

The choice for the "default" default have room to discuss, but format 
may not be bad choice.


As to the current spec, we can emphasize the Turkish issue more visible 
by making "Notes:" to @apiNote.


Naoto

On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:

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 it this way: The Turkish population alone is 
currently 1.08 percent of the world population. If we assume the number 
of Java apps/services per capita is the same around the world, this 
means that these methods may return the expected result in 98.92 percent 
of the executions. I think that's a bit scary.


Deprecating these methods would require consensus and support from 
reviewers, which we don't seem to have at the moment. So I think the 
current focus on fixing the uses inside OpenJDK and then adding 
alternatives first seems good. Then, maybe someday.. :-)


Eirik.

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

[Brian Burkhalter]

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 Marwell 
mailto:bmarw...@apache.org>> wrote:

Follow up, I would highly appreciate it if anyone would be so kind as
to open an issue for this enhancement.

Am Sa., 8. Apr. 2023 um 17:36 Uhr schrieb Benjamin Marwell
mailto:bmarw...@apache.org>>:

Dear Core-Devs,

There was a PR created for an enhancement of SequenceInputStream [1]
by Romain Manni-Buceau.

Description by Romain:

enumeration(list) will create an enumeration, a list and an iterator whereas 
the impl only requires an iterator
this PR drops the enumeration wrapper for binary constructor and just maps the 
enumeration to an iterator for the other case which should be a better 
compromise in practise.

Another side but nice effect is to have some lighter classloading (subgraph)

As the both of us do not have access to the OpenJDK bug tracker,
kindly open an issue for this PR if you agree with this
enhancement/PR.

[1]: https://github.com/openjdk/jdk/pull/11718

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

[Eirik Bjørsnøs]

>
> 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 it this way: The Turkish population alone is
currently 1.08 percent of the world population. If we assume the number of
Java apps/services per capita is the same around the world, this means that
these methods may return the expected result in 98.92 percent of the
executions. I think that's a bit scary.

Deprecating these methods would require consensus and support from
reviewers, which we don't seem to have at the moment. So I think the
current focus on fixing the uses inside OpenJDK and then adding
alternatives first seems good. Then, maybe someday.. :-)

Eirik.

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

[Archie Cobbs]

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 most of the warnings were false
positives. But the argument here is that (quoting): "**Almost all** use
cases of these two methods are misuse"

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?)

-Archie

-- 
Archie L. Cobbs

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

[Glavo]

>  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 agreement on the naming is likely the hard part.
> You might want to start a discussion about that; but it may be too soon
> for a PR.
>

I thought it might be more efficient to discuss after creating a draft PR.
It seems that it is difficult to attract more experts to participate in the
discussion only on the mailing list. Do you have any suggestions for this?

Glavo

On Thu, Apr 13, 2023 at 10:13 PM Roger Riggs  wrote:

> 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 would also be able to suggest and apply.
>
> 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.
>
> An expectation-wise, the June 8 Rampdown Phase One is closer than it
> appears.
> There are significant number of projects that are queuing up to beat the
> deadline, but compete for resources to review.
>
> Regards, Roger
>
>
> On 4/13/23 3:34 AM, Glavo wrote:
>
> 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 misuses, making it
> difficult
> to distinguish between correct use and misuse. Replacing them with
> toLowerCase(Locale.getDefault()) can express intentions more clearly.
> So is it a problem to cause many warnings? I think it's obviously not.
>
> Even these misuses happen to work in most locales, not dealing with them
> is just
> burying the head in the sand.
>
> The topics of deprecation and a new API should be treated separately,
>> they have different costs and benefits.
>>
>
> This PR is now only deprecating the old method.
>
> I plan to perform a set of tasks in parallel:
>
> * Create a series of PRs to replace their use cases module by module with
>   toLowerCase(Locale)/toUpperCase(Locale);
> * Determine the naming of the new methods and then create a PR to
> implement it;
> * Deprecate the old methods.
>
> If no one has any objections to this, I would like to start them
> immediately as
> I hope to complete them before Java 21.
>
> After the above work is completed, I can gradually replace
> `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
> with the new API. This work is not urgent and can be carried out at any
> time.
>
> Glavo
>
> On Thu, Apr 13, 2023 at 4:27 AM Roger Riggs 
> wrote:
>
>> Hi,
>>
>> The status quo takes a balance between trying do the right thing and
>> creating a headache for lots of developers.
>> Deprecating the existing methods would cause lots of warnings and
>> provide little actual improvement.
>> Except in a few locales, the output would be the same as today.
>> If you're working in a locale where it matters, it has become habit to
>> use Locale.root everywhere.
>>
>> The most positive suggestion from the January thread [1] was to fix the
>> uses in the JDK in small batches and carefully review each to make sure
>> there are no unintended consequences. Even replacing the existing uses
>> with a new method requires the same cautious approach.  Adding new
>> methods was also mentioned.
>>
>> The topics of deprecation and a new API should be treated separately,
>> they have different costs and benefits.
>>
>> As observed, coming to agreement on the naming is likely the hard part.
>> You might want to start a discussion about that; but it may be too soon
>> for a PR.
>>
>> Regards, Roger
>>
>>
>>
>> On 4/11/23 4:02 PM, Glavo wrote:
>> > Hi everyone,
>> >
>> > A few months ago, I discussed in this mailing list[1] whether
>> > toLowerCase()/toUpperCase() should be deprecated.
>> > At that time, I received some approval and no one opposed the
>> > idea. Therefore, I thought it might be time
>> > to continue advancing this work, so I created a PR[2] for this.
>> >
>> > This PR is still a draft, welcome to discuss it there.
>> >
>> > I don't have much experience in contributing to OpenJDK yet, so I also
>> > hope to get the help of experienced
>> > contributors (such as creating CSR). Thanks!
>> >
>> > Glavo
>> >
>> > [1]
>> >
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>> > [2] https://github.com/openjdk/jdk/pull/13434
>> 

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

[Roger Riggs]

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 would also be able to suggest and apply.

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.


An expectation-wise, the June 8 Rampdown Phase One is closer than it 
appears.
There are significant number of projects that are queuing up to beat the 
deadline, but compete for resources to review.


Regards, Roger


On 4/13/23 3:34 AM, Glavo wrote:


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 misuses, making it 
difficult

to distinguish between correct use and misuse. Replacing them with
toLowerCase(Locale.getDefault()) can express intentions more clearly.
So is it a problem to cause many warnings? I think it's obviously not.

Even these misuses happen to work in most locales, not dealing with 
them is just

burying the head in the sand.

The topics of deprecation and a new API should be treated separately,
they have different costs and benefits.


This PR is now only deprecating the old method.

I plan to perform a set of tasks in parallel:

* Create a series of PRs to replace their use cases module by module with
  toLowerCase(Locale)/toUpperCase(Locale);
* Determine the naming of the new methods and then create a PR to 
implement it;

* Deprecate the old methods.

If no one has any objections to this, I would like to start them 
immediately as

I hope to complete them before Java 21.

After the above work is completed, I can gradually replace 
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
with the new API. This work is not urgent and can be carried out at 
any time.


Glavo

On Thu, Apr 13, 2023 at 4:27 AM Roger Riggs  
wrote:


Hi,

The status quo takes a balance between trying do the right thing and
creating a headache for lots of developers.
Deprecating the existing methods would cause lots of warnings and
provide little actual improvement.
Except in a few locales, the output would be the same as today.
If you're working in a locale where it matters, it has become
habit to
use Locale.root everywhere.

The most positive suggestion from the January thread [1] was to
fix the
uses in the JDK in small batches and carefully review each to make
sure
there are no unintended consequences. Even replacing the existing
uses
with a new method requires the same cautious approach.  Adding new
methods was also mentioned.

The topics of deprecation and a new API should be treated separately,
they have different costs and benefits.

As observed, coming to agreement on the naming is likely the hard
part.
You might want to start a discussion about that; but it may be too
soon
for a PR.

Regards, Roger



On 4/11/23 4:02 PM, Glavo wrote:
> Hi everyone,
>
> A few months ago, I discussed in this mailing list[1] whether
> toLowerCase()/toUpperCase() should be deprecated.
> At that time, I received some approval and no one opposed the
> idea. Therefore, I thought it might be time
> to continue advancing this work, so I created a PR[2] for this.
>
> This PR is still a draft, welcome to discuss it there.
>
> I don't have much experience in contributing to OpenJDK yet, so
I also
> hope to get the help of experienced
> contributors (such as creating CSR). Thanks!
>
> Glavo
>
> [1]
>
https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> [2] https://github.com/openjdk/jdk/pull/13434

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

[Jim Laskey]

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.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a 
>> lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/util/Digits.java line 39:
> 
>> 37:  * @since 21
>> 38:  */
>> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> The Digits utility implementation class is not public and would be useful 
> elsewhere before JEP 430 is final.
> The PreviewFeature annotation is not needed and would impede its use else 
> where, for example, in HexFormat.

Removing preview feature.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165543387

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

[Jim Laskey]

> 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 and 
> transformation. This is a [preview language feature and 
> API](http://openjdk.java.net/jeps/12).

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

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5e0dfce9..69f49bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=10889=58
 - incr: https://webrevs.openjdk.org/?repo=jdk=10889=57-58

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

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

[Roger Riggs]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a 
> lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/Digits.java line 39:

> 37:  * @since 21
> 38:  */
> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

The Digits utility implementation class is not public and would be useful 
elsewhere before JEP 430 is final.
The PreviewFeature annotation is not needed and would impede its use else 
where, for example, in HexFormat.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165524941

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

[Jim Laskey]

> 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 and 
> transformation. This is a [preview language feature and 
> API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional 
commit since the last revision:

  Recommended changes

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f1b187a1..5e0dfce9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=10889=57
 - incr: https://webrevs.openjdk.org/?repo=jdk=10889=56-57

  Stats: 38 lines in 7 files changed: 14 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

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

[Jim Laskey]

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 updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a 
>> lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:
> 
>> 111: @Override
>> 112: public String toString() {
>> 113: return "java.util.WeakKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

Moved and not reflected in the string. Changing to 
`this.getClass().getCanonicalName() + "#" + System.identityHashCode(this);`

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:
> 
>> 170: @Override
>> 171: public String toString() {
>> 172: return "java.util.SoftKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:
> 
>> 224: @Override
>> 225: public String toString() {
>> 226: return "java.util.StrongKey#" + 
>> System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 
> 130:
> 
>> 128: }
>> 129: 
>> 130: @java.lang.Override
> 
> Suggestion:
> 
> @Override

One of those IntelliJ things - ugh.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 
> 131:
> 
>> 129: 
>> 130: @java.lang.Override
>> 131: public java.lang.String toString() {
> 
> Suggestion:
> 
> public String toString() {

same

> src/java.base/share/classes/java/util/FormatItem.java line 71:
> 
>> 69: MethodType.methodType(MethodHandle.class, 
>> long.class));
>> 70: 
>> 71: private static final long charMix(long lengthCoder, char value) {
> 
> let's drop `final` modifier from `static` methods

Changing

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165449867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450204
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450363
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452561
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452753
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165456644

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

[Jim Laskey]

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 updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a 
>> lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 286:
> 
>> 284:  */
>> 285: MethodHandle constructor(CarrierShape carrierShape) {
>> 286: int longCount = carrierShape.longCount();
> 
> `longCount`/`intCount` seems unused in this method

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 369:
> 
>> 367:  * Cache mapping {@link MethodType} to previously defined 
>> {@link CarrierElements}.
>> 368:  */
>> 369: private static Map
> 
> Can it be made `final` ?

Changing

> src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java line 
> 28:
> 
>> 26: package jdk.internal.access;
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
> 
> Couple of unused imports

Changing

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165440095
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165439152
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165442266

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

[Jim Laskey]

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.
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java 
> line 112:
> 
>> 110: }
>> 111: interpolateMH = MethodHandles.filterArguments(interpolateMH, 0, 
>> components);
>> 112: mt = MethodType.methodType(String.class, 
>> StringTemplateImpl.class);
> 
> This MethodType can be stored in a static final field than created every time 
> on the fly. Don't know if JIT compiler can inline this statement. Same fore 
> that `List.class, StringTemplateImpl.class` type below.

Changing

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165433226

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

[Jim Laskey]

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 line 109:
> 
>> 107:  * @param lookup  method lookup
>> 108:  * @param namemethod name
>> 109:  * @param typemethod type
> 
> Maybe mention that the name is ignored, and the type must be convertible from 
> `(String[], Object[])StringTemplate`? The specification says "fragments list" 
> and "values list", which are more accurately described as arrays.
> 
> Also, does "large" string template mean there are more than 250~ fragments 
> that the bootstrap method arguments can't fit, or does it mean dynamic number 
> of fragments? Might be worth mentioning that as well.

Updating comments

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165418717

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

[Eirik Bjorsnos]

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 not receive any comments.

It would be good if a Reviewer can take a look at the release note and see if 
it is conforming to the desired style:

https://bugs.openjdk.org/browse/JDK-8304459

Thanks!

-

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1506755336

Re: Question: Review process of release notes

[Eirik Bjørsnøs]

>
>
> 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

[David Holmes]

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 the PR is approved, but I guess I'm safe to 
assume so.


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.


Cheers,
David


Cheers,
Eirik.

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

[Andrey Turbanov]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a 
> lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/FormatItem.java line 71:

> 69: MethodType.methodType(MethodHandle.class, 
> long.class));
> 70: 
> 71: private static final long charMix(long lengthCoder, char value) {

let's drop `final` modifier from `static` methods

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165274119

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

[Eirik Bjørsnøs]

>
> 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 code.

Thanks,
Eirik.

>

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

[Eirik Bjørsnøs]

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 could improve the Notes in these somewhat suspicious methods.

The current notes look like this:

Note: This method is locale sensitive, and may produce unexpected
> results if used for strings that are intended to be interpreted locale
> independently.


Sensitive to which locale? Independently of which locale?

It then goes on to say:

To obtain correct results for locale insensitive strings, use
> toUpperCase(Locale.ROOT)


What are "locale insensitive strings"?

Here is an attempt to be more specific:

Note: This method is sensitive to the default locale for this instance
> of the Java Virtual Machine. It  may produce unexpected
> results if used for strings that are intended to be interpreted
> independent of the default locale.


For the last part, I suggest using "language/country neutral results"
instead of "locale insensitive strings":

To obtain language/country neutral results, use toLowerCase(Locale.ROOT)


Any thoughts?

Thanks,
Eirik.
[1] https://github.com/openjdk/jdk/pull/13434#issuecomment-1505832883

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

[Andrey Turbanov]

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 evaluating that expression, possibly after further validation and 
>> transformation. This is a [preview language feature and 
>> API](http://openjdk.java.net/jeps/12).
>
> 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.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a 
> lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:

> 111: @Override
> 112: public String toString() {
> 113: return "java.util.WeakKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:

> 170: @Override
> 171: public String toString() {
> 172: return "java.util.SoftKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:

> 224: @Override
> 225: public String toString() {
> 226: return "java.util.StrongKey#" + 
> System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 130:

> 128: }
> 129: 
> 130: @java.lang.Override

Suggestion:

@Override

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 131:

> 129: 
> 130: @java.lang.Override
> 131: public java.lang.String toString() {

Suggestion:

public String toString() {

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130712
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130798
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165132919
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133244
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133383

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

[Glavo]

>
> 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 misuses, making it
difficult
to distinguish between correct use and misuse. Replacing them with
toLowerCase(Locale.getDefault()) can express intentions more clearly.
So is it a problem to cause many warnings? I think it's obviously not.

Even these misuses happen to work in most locales, not dealing with them is
just
burying the head in the sand.

The topics of deprecation and a new API should be treated separately,
> they have different costs and benefits.
>

This PR is now only deprecating the old method.

I plan to perform a set of tasks in parallel:

* Create a series of PRs to replace their use cases module by module with
  toLowerCase(Locale)/toUpperCase(Locale);
* Determine the naming of the new methods and then create a PR to implement
it;
* Deprecate the old methods.

If no one has any objections to this, I would like to start them
immediately as
I hope to complete them before Java 21.

After the above work is completed, I can gradually replace
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
with the new API. This work is not urgent and can be carried out at any
time.

Glavo

On Thu, Apr 13, 2023 at 4:27 AM Roger Riggs  wrote:

> Hi,
>
> The status quo takes a balance between trying do the right thing and
> creating a headache for lots of developers.
> Deprecating the existing methods would cause lots of warnings and
> provide little actual improvement.
> Except in a few locales, the output would be the same as today.
> If you're working in a locale where it matters, it has become habit to
> use Locale.root everywhere.
>
> The most positive suggestion from the January thread [1] was to fix the
> uses in the JDK in small batches and carefully review each to make sure
> there are no unintended consequences. Even replacing the existing uses
> with a new method requires the same cautious approach.  Adding new
> methods was also mentioned.
>
> The topics of deprecation and a new API should be treated separately,
> they have different costs and benefits.
>
> As observed, coming to agreement on the naming is likely the hard part.
> You might want to start a discussion about that; but it may be too soon
> for a PR.
>
> Regards, Roger
>
>
>
> On 4/11/23 4:02 PM, Glavo wrote:
> > Hi everyone,
> >
> > A few months ago, I discussed in this mailing list[1] whether
> > toLowerCase()/toUpperCase() should be deprecated.
> > At that time, I received some approval and no one opposed the
> > idea. Therefore, I thought it might be time
> > to continue advancing this work, so I created a PR[2] for this.
> >
> > This PR is still a draft, welcome to discuss it there.
> >
> > I don't have much experience in contributing to OpenJDK yet, so I also
> > hope to get the help of experienced
> > contributors (such as creating CSR). Thanks!
> >
> > Glavo
> >
> > [1]
> >
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> > [2] https://github.com/openjdk/jdk/pull/13434
>
>

Re: Question: Review process of release notes

[Eirik Bjørsnøs]

>
> 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

[David Holmes]

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 an 
example:


https://bugs.openjdk.org/browse/JDK-8304459 



The PR is approved and integrated and the issue Resolved as Fixed. 
However, the Release Note sub-task is still New and Unresolved


Questions:

- Is the Release note issue considered implicitly reviewed as part of 
the PR process?
- Now that the issue is integrated, what should I do with the Release 
Note issue? Mark it as fixed in 21 and resolve it?
- The referenced release note does not appear in 
https://jdk.java.net/21/ , that's perhaps 
because the JBS issue is not resolved?


Thanks,
Eirik.

Integrated: 8304450: [vectorapi] Refactor VectorShuffle implementation

[Quan Anh Mai]

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 conversions between a shuffle and its corresponding vector. 
> This hinders the performance when the shuffle indices are not constant and 
> are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems 
> that a shuffle index vector is always expanded to the correct type before 
> executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as 
> special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is 
> inefficient for FP types since both FP conversions and FP comparisons are 
> more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
> var species = IntVector.SPECIES_128;
> var v1 = IntVector.fromArray(species, SRC1, 0);
> var v2 = IntVector.fromArray(species, SRC2, 0);
> v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
> Before:
> movabs $0x751589fa8,%r10;   {oop([I{0x000751589fa8})}
> vmovdqu 0x10(%r10),%xmm2
> movabs $0x7515a0d08,%r10;   {oop([I{0x0007515a0d08})}
> vmovdqu 0x10(%r10),%xmm1
> movabs $0x75158afb8,%r10;   {oop([I{0x00075158afb8})}
> vmovdqu 0x10(%r10),%xmm0
> vpand  -0xddc12(%rip),%xmm0,%xmm0# Stub::vector_int_to_byte_mask
> ;   
> {external_word}
> vpackusdw %xmm0,%xmm0,%xmm0
> vpackuswb %xmm0,%xmm0,%xmm0
> vpmovsxbd %xmm0,%xmm3
> vpcmpgtd %xmm3,%xmm1,%xmm3
> vtestps %xmm3,%xmm3
> jne0x7fc2acb4e0d8
> vpmovzxbd %xmm0,%xmm0
> vpermd %ymm2,%ymm0,%ymm0
> movabs $0x751588f98,%r10;   {oop([I{0x000751588f98})}
> vmovdqu %xmm0,0x10(%r10)
> 
> After:
> movabs $0x751589c78,%r10;   {oop([I{0x000751589c78})}
> vmovdqu 0x10(%r10),%xmm1
> movabs $0x75158ac88,%r10;   {oop([I{0x00075158ac88})}
> vmovdqu 0x10(%r10),%xmm2
> vpxor  %xmm0,%xmm0,%xmm0
> vpcmpgtd %xmm2,%xmm0,%xmm3
> vtestps %xmm3,%xmm3
> jne0x7fa818b27cb1
> vpermd %ymm1,%ymm2,%ymm0
> movabs $0x751588c68,%r10;   {oop([I{0x000751588c68})}
> vmovdqu %xmm0,0x10(%r10)
> 
> Please take a look and leave reviews. Thanks a lot.

This pull request has now been integrated.

Changeset: e846a1d7
Author:Quan Anh Mai 
URL:   
https://git.openjdk.org/jdk/commit/e846a1d70043f7b57ae76847e85e5426c86539a5
Stats: 3690 lines in 64 files changed: 1615 ins; 1169 del; 906 mod

8304450: [vectorapi] Refactor VectorShuffle implementation

Reviewed-by: psandoz, xgong, jbhateja, vlivanov

-

PR: https://git.openjdk.org/jdk/pull/13093

Question: Review process of release notes

[Eirik Bjørsnøs]

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 as Fixed. However,
the Release Note sub-task is still New and Unresolved

Questions:

- Is the Release note issue considered implicitly reviewed as part of the
PR process?
- Now that the issue is integrated, what should I do with the Release Note
issue? Mark it as fixed in 21 and resolve it?
- The referenced release note does not appear in https://jdk.java.net/21/,
that's perhaps because the JBS issue is not resolved?

Thanks,
Eirik.

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

[Per Minborg]

> 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
> - [ ] Tier3
> - [ ] Tier4
> - [ ] Tier5
> - [ ] Tier6

Per Minborg has updated the pull request incrementally with two additional 
commits since the last revision:

 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/6164abe8..91f43d13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=13079=22
 - incr: https://webrevs.openjdk.org/?repo=jdk=13079=21-22

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079