Stripping of Locales in JDK17

[knocknarea]

@axelfontaine

Our application has a variety of locales supported, however deploying via CloudCaptain is creating havok as it appears that NO locales are supported (other than US) on the resultant JVM used by CloudCaptain.

We use available language locales linked via country codes to determine whether certain language features and educational programmes are available to the end user. A feature that is now broken on our production systems.

This is not a problem on locally run instances on JDK 17 (outside of CloudCaptain)

A little debug output on my side of sample country codes, as Country Code to Supported Languages, through locale queries:

Locally running on Naked JDK (17). No CloudCaptain

CountryCodeUtil - Supported Locale for Country DE => [de, ksh, dsb, hsb, en, nds]
CountryCodeUtil - Supported Locale for Country IE => [en, ga]
CountryCodeUtil - Supported Locale for Country OM => [ar]
CountryCodeUtil - Supported Locale for Country ZA => [xh, af, en, zu]
CountryCodeUtil - Supported Locale for Country CH => [de, pt, en, wae, gsw, rm, it, fr]
CountryCodeUtil - Supported Locale for Country GB => [cy, en, ga, kw, gd]

CloudCaptain deployment on JDK 17 (irrespective or profile)

CountryCodeUtil - Supported Locale for Country DE => []
CountryCodeUtil - Supported Locale for Country IE => []
CountryCodeUtil - Supported Locale for Country OM => []
CountryCodeUtil - Supported Locale for Country ZA => []
CountryCodeUtil - Supported Locale for Country CH => []
CountryCodeUtil - Supported Locale for Country GB => []

This is an urgent issue for us. Any workarounds in the meantime would be greatly appreciated.

[axelfontaine]

In this case, given the urgency, our custom JRE "escape hatch" is probably the best choice for you: https://cloudcaptain.sh/docs/payloads/springboot#custom-jre

You can build your JRE using jlink with just the modules you need.

[knocknarea]

Ohh. Ouch. Thank you for the pointer all the same, and good to know it's there as an option.

However, checking a custom jre into a repo is a tough choice to make for what should be a non issue.

Not meaning to sound ungrateful for your response and appreciation of such a great product, but the custom jre option should be the other way around, I.e if you are dropping locales through jlink. The jre default supplied by cloudcaptain should be what it's expected to be and not have these trapdoors (taking the other two issues I've raised into account)

Any idea of a timeline to fix this if I work around it in code until then? Is it a major rework on your side?

[axelfontaine]

@knocknarea Sorry for the delay. For OpenJDK 11 and 17 we actually didn't build anything ourselves. Instead we used the x64 "server JRE" distribution of AdoptOpenJDK. I have now pushed the 17.0.5 release from Eclipse Temurin (AdoptOpenJDK's successor) to the Boxfuse Inventory. This is no longer a "server JRE". Instead it is a slightly larger regular "JRE". Please confirm that everything is now working as expected.

[axelfontaine]

Is this now working as expected?

[knocknarea]

@axelfontaine Yes it is. Thank you. I only got around to, removing the workaround and testing this today and it's fine with 17.0.5. Much appreciated.