Default locale selection at login is inconsistent


In our conf we have cuba.availableLocales = Français|fr;English|en and cuba.localeSelectVisible = false.

Default is then expected to be FR but it is not. So we need to keep localeSelectVisible to true to work around that.

Through debugging it appears that AbstratctauthenticationProvider is selecting a default locale (code below) when user language is not defined with messages.getTools().getDefaultLocale().

protected Locale getUserLocale(LocalizedCredentials credentials, User user) {
        Locale userLocale = null;
        if (credentials.isOverrideLocale()) {
            userLocale = credentials.getLocale();
        if (userLocale == null) {
            if (user.getLanguage() != null) {
                userLocale = LocaleUtils.toLocale(user.getLanguage());
            } else {
                userLocale = messages.getTools().trimLocale(messages.getTools().getDefaultLocale());

        return userLocale;

MessageTools.getDefaultLocale() (below) claims that it will return the “first locale from the list”.

     * @return first locale from the list defined in {@code cuba.availableLocales} app property, taking into
     * account {@link #useLocaleLanguageOnly()} return value.
    public Locale getDefaultLocale() {
        if (globalConfig.getAvailableLocales().isEmpty())
            throw new DevelopmentException("Invalid cuba.availableLocales application property");
        return **globalConfig.getAvailableLocales().entrySet().iterator().next().getValue();**

But this cannot be guaranteed when using Map.iterator().next(), except if using an ordered Map like LinkedHashMap, and this is not the case (see AvailableLocalesFactory below)

public class AvailableLocalesFactory extends TypeFactory {

    public Object build(String string) {
        if (string == null)
            return null;

                .map(item -> item.split("\\|"))
                        parts -> parts[0],
                        parts -> LocaleUtils.toLocale(parts[1])

Hi Mike,
Thank you for the report and investigation.
The fix will be available in the next updates of the 6.7 and 6.8 releases:

Thanks Konstantin, you’re welcome.