jlink and jdk.localedata

[Alan Bateman]

On 23/08/2016 20:49, Sander Mak wrote:

> :
>
> I can see how this happens: jdk.localedata is not automatically resolved because it is based on services, and there's a silent fallback to en_US if the nl_NL locale is not found. All perfectly explainable from a module-system technical point of view, but I think this will lead to lots of confused looks in applications relying on locales other than English locales. Not sure what to propose here, other than that this should be very well documented IMO. Maybe jlink could at least warn if the user's system locale is not among the default ones from java.base and suggest to add jdk.localedata to preserve local behavior. Granted, the image is probably targeted to other environments, but at least it's something.
>
>
A few things to mention on this:

1. It's an open issue in JEP 282 [1] as to whether jlink should support 
service binding.

2. The only required installed Locale is en_US, specified in 
java.util.Locale. I think at one point that the JRE download on Windows 
used to have a variant that didn't include all the locales in order to 
reduce the download size. You'll see similar issues with the extended 
charsets where java.base has the all the specified standard charsets, 
other extended charsets are in the jdk.charsets service provider module.

3. I don't know if you've found it yet but there is a jlink plugin for 
customizing the locales that are included in the run time image. In this 
case, you could use `--add-modules jdk.localedata --include-locales nl` 
(the value to --include-locales is the BCP 47 language tag). The main 
motive for this plugin is embedded builds where footprint is important 
and where you have some idea as to the countries or regions where the 
device will be used.

-Alan

[1] http://openjdk.java.net/jeps/282