[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: jlink and jdk.localedata
From:       Sander Mak <sander.mak () luminis ! eu>
Date:       2016-08-24 11:22:28
Message-ID: 5A6C9C85-2451-402E-9CC6-210543FACC73 () luminis ! eu
[Download RAW message or body]


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

Yes, and I can see how it's a bit of a 'damned if you do, damned if you don't' \
situation. An idea: maybe have jlink output unbound service consumers as useful \
feedback for the packager after creating the image? Or in general, a diagnostic flag \
that outputs the provider/consumer wiring given the currently resolved modules. 

> 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.

Thanks for the pointer on jdk.charsets.

> 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.

Indeed, exploring this plugin is what led me to jdk.localedata. The size reduction is \
more significant than I would've anticipated!


Sander


[prev in list] [next in list] [prev in thread] [next in thread]