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
