"WARNING: Please note that for ICU 78 (2025-oct) we are planning to remove the ICU4J Locale Service Provider. See the ICU 77 page for details."
https://unicode-org.github.io/icu/userguide/icu4j/locale-service-provider.html
I am part of the ICU team, and this is a "courtesy ticket"
I did a quick check of the code at LOCKSS Core.
The code does not seem to use anything Locale Service Provider related.
It seem to use CharsetDetector and CharsetMatch directly (from com.ibm.icu.text), in one file, but that does not need anything from localespi.
I also searched for java.locale.providers, and for java.ext.dirs (which would be needed in order to "activate" the Java Locale Service Provider mechanism).
And neither of them is mentioned anywhere.
So in theory just removing the icu4j-localespi from dependencies should be enough.
If the code really needs to the latest version of locale data provided by ICU4J and I didn't find it,
then using directly the icu classes (ULocale, com.ibm.icu.text.DateFormat, and so on) is an alternative to localespi.
Thank you,
Mihai
I am part of the ICU team, and this is a "courtesy ticket"
I did a quick check of the code at LOCKSS Core.
The code does not seem to use anything Locale Service Provider related.
It seem to use
CharsetDetectorandCharsetMatchdirectly (fromcom.ibm.icu.text), in one file, but that does not need anything fromlocalespi.I also searched for
java.locale.providers, and forjava.ext.dirs(which would be needed in order to "activate" the Java Locale Service Provider mechanism).And neither of them is mentioned anywhere.
So in theory just removing the icu4j-localespi from dependencies should be enough.
If the code really needs to the latest version of locale data provided by ICU4J and I didn't find it,
then using directly the icu classes (
ULocale,com.ibm.icu.text.DateFormat, and so on) is an alternative to localespi.Thank you,
Mihai