Locales default set at run-time starting with GraalVM/Mandrel 24.2 for JDK 24, how to handle in Quarkus? #43533
Replies: 4 comments 13 replies
-
|
As an example compiling and running the following code compiled with import java.util.Locale;
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World! The default locale is " + Locale.getDefault());
for (Locale availableLocale : Locale.getAvailableLocales()) {
System.out.println(availableLocale);
}
}
}gives the following results in the corresponding version:
Note that the locale of the system I build on is If I recompile using
|
Beta Was this translation helpful? Give feedback.
-
That would have been my next question. And I think that this the core question: do we want some code to provide the "old" behaviour? If so: should it be the default? Or do we just want to have the "new way" and be done with it? I see where you are coming from. But I think that having the "legacy" behaviour is worth while, since this is a non-trivial change and may lead to nasty bugs for end users. |
Beta Was this translation helpful? Give feedback.
-
|
IMO the build locale should not affect the supported locales of the produced binary. It should be driven entirely by |
Beta Was this translation helpful? Give feedback.
-
|
So, do you suggest that?
For points 2 and 3 starting with graalVM for JDK 24 we will also include |
Beta Was this translation helpful? Give feedback.
-
Also yes to ignore the current OS locale at startup if |
Beta Was this translation helpful? Give feedback.
-
I like this idea. |
Beta Was this translation helpful? Give feedback.
-
|
There's something missing from your explanation, I think: https://quarkus.io/guides/all-config#quarkus-core_quarkus-locales
The default value is: Sounds to me like Confusingly, |
Beta Was this translation helpful? Give feedback.
-
Well, that's actually the current Quarkus behavior. See so I guess we should improve the documentation :)
I guess that's because they are now deprecated. |
Beta Was this translation helpful? Give feedback.
-
|
OK, we need to fix the docs, then. |
Beta Was this translation helpful? Give feedback.
-
|
There was a zulip discussion leading to this: #43578 |
Beta Was this translation helpful? Give feedback.
-
|
@brunobat are you suggesting that we should consider a similar approach for locales? |
Beta Was this translation helpful? Give feedback.
-
|
Just that the solution should play ball with this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Is the rationale for the change in graalvm just "be more like jvm" ? what is the actual behavior we think would be nice? I'm assuming its one where we can limit how many locales data gets included into the image? Is that still possible in latest graalvm 24? |
Beta Was this translation helpful? Give feedback.
-
Yes, but not just for the sake it of it -- it also makes sense to be able to choose any of the included locales as the default one.
IMO users should be able to ship their apps with a number of supported locales and have the option to use any of them as the default one.
Yes, that's still possible. We are just able to also start the application with a different default locale, while with previous versions the default locale was fixed. |
Beta Was this translation helpful? Give feedback.
-
With GraalVM/Mandrel prior to 24.2.0 the default locale (and included locale) for a native executable was determined (and implicitly included in the image) by either:
user.languageanduser.countryor
quarkus.default-localeor
quarkus.native.user-languageandquarkus.native.country(Deprecated)settings at native executable build time.
Starting with GraalVM/Mandrel 24.2.0 for JDK 24 the build settings of language/country have no effect in terms of included locales (as in the build time locale is not included implicitly) in the resulting native executable. Furthermore, the default locale is determined at runtime based on the locale of the system the native executable runs on, which is on par with how it works in JVM-mode, with the notable difference that if one wants to use a locale not explicitly added to the image it won't work (it will fallback to English).
#43448 takes a step towards handling this, by automatically including in the native executable the locale defined by either:
quarkus.default-localeor
quarkus.native.user-languageandquarkus.native.country(Deprecated)but doesn't consider
user.languagenoruser.country.The questions are:
user.languageanduser.countryproperties to the above list?quarkus.localesand ignore the build-time default locale?Beta Was this translation helpful? Give feedback.
All reactions