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
