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?
