<i18n dev> Trouble adding a JavaTimeDateTimePatternProvider implementation

[Naoto Sato]

Hi,

Unfortunately, the `SPI` provider is designed to provide SPI 
implementations, not the locale providers (set of SPI implementations) 
such as COMPAT, CLDR, or HOST. I believe the interface you referred to 
is the internal implementation class to supplement COMPAT with some 
lacking functionalities for java.time APIs, which is not public.

I think what I can recommend here is to migrate customer's environment 
to CLDR. In fact, choosing COMPAT is now deprecated as of JDK21 (emits a 
warning message on startup).

Naoto


On 9/11/23 11:40 AM, Tyler Kindy wrote:
> Hello all,
> 
> I'm working on a migration in one of my company's services from the 
> JRE's locale dataset to the Unicode CLDR. We're upgrading individual 
> customers at a time, so we need to be able to dynamically switch between 
> the two datasets at runtime depending on which customer we're processing 
> a request for.
> 
> The approach I've been prototyping uses the LocaleProviderAdapter SPI. 
> I'm implementing service providers for the various subclasses of 
> LocaleServiceProvider which select the dataset to use in the current 
> context and delegate to either the JRE or CLDR implementations 
> accordingly. I've made good strides with NumberFormatProvider and 
> DateFormatProvider, however I tried to implement 
> JavaTimeDateTimePatternProvider and ran into an exception:
> 
> ClassNotFoundException: 
> sun/util/locale/provider/SPILocaleProviderAdapter$JavaTimeDateTimePatternProviderDelegate
> 
> It seems most service provider interfaces have some kind of delegate 
> class defined in SPILocaleProviderAdapter, but 
> JavaTimeDateTimePatternProvider doesn't have one. Is that intentional? 
> Is there another way I can implement a service provider for this 
> particular interface?
> 
> I'd also appreciate general feedback on my approach. If there's a better 
> way to achieve this dynamic switching between JRE and CLDR data using 
> the standard platform APIs, I'd love to hear about it.
> 
> Thank you,
> Tyler Kindy