-
Type:
Bug
-
Resolution: Cannot Reproduce
-
Priority:
P4
-
None
-
Affects Version/s: None
-
Component/s: core-libs
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
JDK Code in places such as https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#L894-L899 is ignoring the configured SPI provider because it is not an instanceof ResourceBundleBasedAdapter. There is similar code in a few other places like DateFormatSymbols too. This renders it virtually impossible to remove the -Djava.locale.providers COMPAT option, replacing it with SPI and custom code to replicate the old JRE/COMPAT localization that doesn't match what CLDR provides.
Are there plans to enhance the SPILocaleProviderAdapter to handle all the use cases that currently require a ResourceBundelBasedAdapter before the COMPAT option is fully removed from the JDK?
In the short term, would it be possible to remove that warning when COMPAT is specified as a locale.provider? It seems 'Unfair' to constantly print that out when it isn't yet possible to remove it and retain (via rewriting) the functionality that it provides.
JDK Code in places such as https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#L894-L899 is ignoring the configured SPI provider because it is not an instanceof ResourceBundleBasedAdapter. There is similar code in a few other places like DateFormatSymbols too. This renders it virtually impossible to remove the -Djava.locale.providers COMPAT option, replacing it with SPI and custom code to replicate the old JRE/COMPAT localization that doesn't match what CLDR provides.
Are there plans to enhance the SPILocaleProviderAdapter to handle all the use cases that currently require a ResourceBundelBasedAdapter before the COMPAT option is fully removed from the JDK?
In the short term, would it be possible to remove that warning when COMPAT is specified as a locale.provider? It seems 'Unfair' to constantly print that out when it isn't yet possible to remove it and retain (via rewriting) the functionality that it provides.