> 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
