jlink and jdk.localedata

[Naoto Sato]

Yes, the fact that java.base module only contains en_US locale data 
should be documented somewhere. We could also note that in the usage 
help for "--include-locales" option of jlink command.

Naoto

On 8/23/16 12:49 PM, Sander Mak wrote:
> Hello,
>
> When I create an image with jlink containing a single module that runs this code:
>
> public static void main(String... args) {
>     Locale dutchLocale = new Locale.Builder().setLanguage("nl")
>             .setRegion("NL").build();
>     DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT, dutchLocale);
>     String formattedDate = df.format(new java.util.Date());
>     System.out.println(formattedDate);
> }
>
> some surprising behavior surfaces. While running on the full JDK this shows the correctly formatted date, running on the image shows the date formatted according to the en_US locale (available through java.base). Adding the jdk.localedata module explicitly to the image fixes this.
>
> 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.
>
>
> Sander
>
>