RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

[Michael Paus]

Am 06.11.19 um 14:07 schrieb Alan Bateman:
> On 06/11/2019 12:24, Michael Paus wrote:
>> But this is also a very dangerous option because it may place time-bombs
>> into your packaged applications. For example, I recently realized 
>> that I could
>> not make any https-requests any more in my packaged application. To fix
>> that I had to explicitly add "jdk.crypto.ec" to the list of modules 
>> for jlink.
>> The symptoms of such bugs are not always very clear and do not
>> directly point you to missing modules with service providers.
>> So there should at least be a big warning that when you do not specify
>> the --bind-services option, you will have to watch out for sometimes
>> obscure runtime errors.
> `jlink` is a power tool that requires its user to have significant 
> knowledge about the application, its dependences, and the environment 
> where the resulting run-time image will be run. If you want to include 
> additional crypto then you have to opt-in, if you want support for all 
> or a subset of locales then you opt-in, and so. If you change the 
> default and eagerly link in all modules then you'll annoy everyone 
> that is looking for a the run-time image to be as small as possible. 
> The best that we could come up with in JDK 9 `--suggest-providers` 
> option to help users get some idea of the providers that could be used 
> at run-time. I don't know if you've used that but if needed then I 
> assume `jpackage` could pass the option through to `jlink` in a dry run.
>
> -Alan

The --suggest-providers option would be more useful if one could limit 
it to the providers that can actually be used by my code, i.e.
a call like

jlink --add-modules java.base --suggest-providers

should only return the providers which can be reached by java.base. Or 
did I miss something here?