JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!

[David Delabassee]

Welcome to the latest OpenJDK Quality Outreach update!

Last week was busy as we released both Java 20 and JavaFX 20. To 
celebrate the launch, we hosted a live event focused on Java 20, i.e. 
Level Up Java Day. All the sessions recordings will be made available 
shortly on the YouTube Java channel.


Some recent events shown us that it is useful to conduct tests using the 
latest early-access OpenJDK builds. This will benefit the OpenJDK 
codebase but also your own codebase. Sometime, a failure could be due to 
an actual regression introduced in OpenJDK. In that case, we obviously 
want to hear about it while we can still address it. But sometime, a 
failure could also be due to a subtle behaviour change… that works as 
expected. Regardless of if it's a bug or a test that is now broken due 
to a behaviour change, we want to hear from you. In the latter case, it 
might also mean that we should probably communicate more about those 
changes even if they might seem subtle. On that note, please make sure 
to check all the 2 Heads-Up below: "Support for Unicode CLDR Version 42" 
and "New network interface names on Windows".


So please, let us know if you observe anything using the latest 
early-access builds of JDK 21.



## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42

The JDK's locale data is based on the Unicode Consortium's Unicode 
Common Locale Data Repository (CLDR). As mentioned in the December 2022 
Quality Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 
[3], which was released in October 2022. This version includes a "more 
sophisticated handling of spaces" [4] that replaces regular spaces with 
non-breaking spaces (NBSP / `\u00A0`) or narrow non-breaking spaces 
(NNBSP / `\u202F`):

- in time formats between `a` and time
- in unit formats between {0} and unit
- in Cyrillic date formats before year marker such as `г`

Other noticeable changes include:
* " at " is no longer used for standard date/time format ’ [5]
* fix first day of week info for China (CN) [6]
* Japanese: Support numbers up to 京 [7]

As a consequence, production and test code that produces or parses 
locale-dependent strings like formatted dates and times may change 
behavior in potentially breaking ways (e.g. when a handcrafted datetime 
string with a regular space is parsed, but the parser now expects an 
NBSP or NNBSP). Issues can be hard to analyze because expected and 
actual strings look very similar or even identical in various text 
representations. To detect and fix these issues, make sure to use a text 
editor that displays different kinds of spaces differently.


If the required fixes can't be implemented when upgrading to JDK 20, 
consider using the JVM argument `-Djava.locale.providers=COMPAT` to use 
legacy locale data. Note that this limits some locale-related 
functionality and treat it as a temporary workaround, not a proper 
solution. Moreover, the `COMPAT` option will be eventually removed in 
the future.


It is also important to keep in mind that this kind of locale data 
evolves regularly so programs parsing/composing the locale data by 
themselves should be routinely checked with each JDK release.


[1] 
https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html

[2] https://bugs.openjdk.org/browse/JDK-8284840
[3] https://cldr.unicode.org/index/downloads/cldr-42
[4] https://unicode-org.atlassian.net/browse/CLDR-14032
[5] https://unicode-org.atlassian.net/browse/CLDR-14831
[6] https://unicode-org.atlassian.net/browse/CLDR-11510
[7] https://unicode-org.atlassian.net/browse/CLDR-15966


## Heads-Up - JDK 21 - New network interface names on Windows

Network Names that the JDK assigns to network interfaces on Windows are 
changing in JDK 21 [8].


The JDK historically synthesized names for network interfaces on 
Windows. This has changed to use the names assigned by the Windows 
operating system. For example, the JDK may have historically assigned a 
name such as “eth0” for an ethernet interface and “lo” for the loopback. 
The equivalent names that Windows assigns may be names such as 
“ethernet_32768” and “loopback_0".


This change may impact code that does a lookup of network interfaces 
with the `NetworkInterace.getByName(String name)` method. It also may 
also be surprising to code that enumerates all network interfaces with 
the `NetworkInterfaces.networkInterfaces()` or 
`NetworkInterface.getNetworkInterfaces()` methods as the names of the 
network interfaces will look different to previous releases. Depending 
on configuration, it is possible that enumerating all network interfaces 
will enumerate network interfaces that weren’t previously enumerated 
because they didn’t have an Internet Protocol address assigned. The 
display name returned by `NetworkInterface::getDisplayName` has not 
changed so this should facilitate the identification of network 
interfaces when using Windows native tools.


[8] https://bugs.openjdk.org/browse/JDK-8303898


## JDK 20 Ge

Re: JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!

[Apache]

We need to look into this now that scoped variables are present.

Ralph

> On Mar 28, 2023, at 5:46 AM, David Delabassee  
> wrote:
> 
> Welcome to the latest OpenJDK Quality Outreach update!
> 
> Last week was busy as we released both Java 20 and JavaFX 20. To celebrate 
> the launch, we hosted a live event focused on Java 20, i.e. Level Up Java 
> Day. All the sessions recordings will be made available shortly on the 
> YouTube Java channel.
> 
> Some recent events shown us that it is useful to conduct tests using the 
> latest early-access OpenJDK builds. This will benefit the OpenJDK codebase 
> but also your own codebase. Sometime, a failure could be due to an actual 
> regression introduced in OpenJDK. In that case, we obviously want to hear 
> about it while we can still address it. But sometime, a failure could also be 
> due to a subtle behaviour change… that works as expected. Regardless of if 
> it's a bug or a test that is now broken due to a behaviour change, we want to 
> hear from you. In the latter case, it might also mean that we should probably 
> communicate more about those changes even if they might seem subtle. On that 
> note, please make sure to check all the 2 Heads-Up below: "Support for 
> Unicode CLDR Version 42" and "New network interface names on Windows".
> 
> So please, let us know if you observe anything using the latest early-access 
> builds of JDK 21.
> 
> 
> ## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42
> 
> The JDK's locale data is based on the Unicode Consortium's Unicode Common 
> Locale Data Repository (CLDR). As mentioned in the December 2022 Quality 
> Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 [3], which 
> was released in October 2022. This version includes a "more sophisticated 
> handling of spaces" [4] that replaces regular spaces with non-breaking spaces 
> (NBSP / `\u00A0`) or narrow non-breaking spaces (NNBSP / `\u202F`):
> - in time formats between `a` and time
> - in unit formats between {0} and unit
> - in Cyrillic date formats before year marker such as `г`
> 
> Other noticeable changes include:
> * " at " is no longer used for standard date/time format ’ [5]
> * fix first day of week info for China (CN) [6]
> * Japanese: Support numbers up to 京 [7]
> 
> As a consequence, production and test code that produces or parses 
> locale-dependent strings like formatted dates and times may change behavior 
> in potentially breaking ways (e.g. when a handcrafted datetime string with a 
> regular space is parsed, but the parser now expects an NBSP or NNBSP). Issues 
> can be hard to analyze because expected and actual strings look very similar 
> or even identical in various text representations. To detect and fix these 
> issues, make sure to use a text editor that displays different kinds of 
> spaces differently.
> 
> If the required fixes can't be implemented when upgrading to JDK 20, consider 
> using the JVM argument `-Djava.locale.providers=COMPAT` to use legacy locale 
> data. Note that this limits some locale-related functionality and treat it as 
> a temporary workaround, not a proper solution. Moreover, the `COMPAT` option 
> will be eventually removed in the future.
> 
> It is also important to keep in mind that this kind of locale data evolves 
> regularly so programs parsing/composing the locale data by themselves should 
> be routinely checked with each JDK release.
> 
> [1] 
> https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
> [2] https://bugs.openjdk.org/browse/JDK-8284840
> [3] https://cldr.unicode.org/index/downloads/cldr-42
> [4] https://unicode-org.atlassian.net/browse/CLDR-14032
> [5] https://unicode-org.atlassian.net/browse/CLDR-14831
> [6] https://unicode-org.atlassian.net/browse/CLDR-11510
> [7] https://unicode-org.atlassian.net/browse/CLDR-15966
> 
> 
> ## Heads-Up - JDK 21 - New network interface names on Windows
> 
> Network Names that the JDK assigns to network interfaces on Windows are 
> changing in JDK 21 [8].
> 
> The JDK historically synthesized names for network interfaces on Windows. 
> This has changed to use the names assigned by the Windows operating system. 
> For example, the JDK may have historically assigned a name such as “eth0” for 
> an ethernet interface and “lo” for the loopback. The equivalent names that 
> Windows assigns may be names such as “ethernet_32768” and “loopback_0".
> 
> This change may impact code that does a lookup of network interfaces with the 
> `NetworkInterace.getByName(String name)` method. It also may also be 
> surprising to code that enumerates all network interfaces with the 
> `NetworkInterfaces.networkInterfaces()` or 
> `NetworkInterface.getNetworkInterfaces()` methods as the names of the network 
> interfaces will look different to previous releases. Depending on 
> configuration, it is possible that enumerating all network interfaces will 
> enumerate network interfaces that weren’t previously enumerated because they 
>

Re: JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!

[Matt Sicker]

Exciting! I’ll note that we have support for the Kotlin equivalent to scoped 
variables in the Kotlin API, and one limitation we have there is that there’s 
no way to easily export and import maps into and out of the thread context. 
There’s some TODO comments left behind and an old Jira ticket, but the idea is 
that besides in unit tests, there are also Kotlin coroutines where we need to 
save and restore parts or all of the current thread context in order to 
populate the equivalent of scoped variables. See 

 for the source there (if you’re unfamiliar with Kotlin, the `ContextMap` and 
`ContextStack` classes are facades for `ThreadContext` map and stack operations 
that support operator overloading).

> On Mar 28, 2023, at 8:21 AM, Apache  wrote:
> 
> We need to look into this now that scoped variables are present.
> 
> Ralph
> 
>> On Mar 28, 2023, at 5:46 AM, David Delabassee  
>> wrote:
>> 
>> Welcome to the latest OpenJDK Quality Outreach update!
>> 
>> Last week was busy as we released both Java 20 and JavaFX 20. To celebrate 
>> the launch, we hosted a live event focused on Java 20, i.e. Level Up Java 
>> Day. All the sessions recordings will be made available shortly on the 
>> YouTube Java channel.
>> 
>> Some recent events shown us that it is useful to conduct tests using the 
>> latest early-access OpenJDK builds. This will benefit the OpenJDK codebase 
>> but also your own codebase. Sometime, a failure could be due to an actual 
>> regression introduced in OpenJDK. In that case, we obviously want to hear 
>> about it while we can still address it. But sometime, a failure could also 
>> be due to a subtle behaviour change… that works as expected. Regardless of 
>> if it's a bug or a test that is now broken due to a behaviour change, we 
>> want to hear from you. In the latter case, it might also mean that we should 
>> probably communicate more about those changes even if they might seem 
>> subtle. On that note, please make sure to check all the 2 Heads-Up below: 
>> "Support for Unicode CLDR Version 42" and "New network interface names on 
>> Windows".
>> 
>> So please, let us know if you observe anything using the latest early-access 
>> builds of JDK 21.
>> 
>> 
>> ## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42
>> 
>> The JDK's locale data is based on the Unicode Consortium's Unicode Common 
>> Locale Data Repository (CLDR). As mentioned in the December 2022 Quality 
>> Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 [3], which 
>> was released in October 2022. This version includes a "more sophisticated 
>> handling of spaces" [4] that replaces regular spaces with non-breaking 
>> spaces (NBSP / `\u00A0`) or narrow non-breaking spaces (NNBSP / `\u202F`):
>> - in time formats between `a` and time
>> - in unit formats between {0} and unit
>> - in Cyrillic date formats before year marker such as `г`
>> 
>> Other noticeable changes include:
>> * " at " is no longer used for standard date/time format ’ [5]
>> * fix first day of week info for China (CN) [6]
>> * Japanese: Support numbers up to 京 [7]
>> 
>> As a consequence, production and test code that produces or parses 
>> locale-dependent strings like formatted dates and times may change behavior 
>> in potentially breaking ways (e.g. when a handcrafted datetime string with a 
>> regular space is parsed, but the parser now expects an NBSP or NNBSP). 
>> Issues can be hard to analyze because expected and actual strings look very 
>> similar or even identical in various text representations. To detect and fix 
>> these issues, make sure to use a text editor that displays different kinds 
>> of spaces differently.
>> 
>> If the required fixes can't be implemented when upgrading to JDK 20, 
>> consider using the JVM argument `-Djava.locale.providers=COMPAT` to use 
>> legacy locale data. Note that this limits some locale-related functionality 
>> and treat it as a temporary workaround, not a proper solution. Moreover, the 
>> `COMPAT` option will be eventually removed in the future.
>> 
>> It is also important to keep in mind that this kind of locale data evolves 
>> regularly so programs parsing/composing the locale data by themselves should 
>> be routinely checked with each JDK release.
>> 
>> [1] 
>> https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
>> [2] https://bugs.openjdk.org/browse/JDK-8284840
>> [3] https://cldr.unicode.org/index/downloads/cldr-42
>> [4] https://unicode-org.atlassian.net/browse/CLDR-14032
>> [5] https://unicode-org.atlassian.net/browse/CLDR-14831
>> [6] https://unicode-org.atlassian.net/browse/CLDR-11510
>> [7] https://unicode-org.atlassian.net/browse/CLDR-15966
>> 
>> 
>> ## Heads-Up - JDK 21 - New network interface names on Windows
>> 
>> Network Names that the JDK assigns to network interfaces on Windows are