On Fri, 7 Feb 2025 16:48:09 GMT, Severin Gehwolf <[email protected]> wrote:
>> The change for JDK-8346434 added a new test case to
>> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
>> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
>> part of the target image.
>> This can be circumvented by limiting the modules.
>
> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 145:
>
>> 143: public void testNoBindServicesByDefault() {
>> 144: final var defaultModules = getModulesInRuntime("--limit-modules
>> java.smartcardio,jdk.crypto.cryptoki,java.desktop");
>> 145: final var modulesWithBindServices =
>> getModulesInRuntime("--bind-services --limit-modules
>> java.smartcardio,jdk.crypto.cryptoki,java.desktop");
>
> Pre-existing: It would be good to document which additional modules in the
> set get dragged in by `--bind-services`. That would allow future readers of
> that test to figure out why a test starts to fail (e.g. by a future change
> removing a provided service in a module).
As far as my testing is concerned it's only `jdk.crypto.cryptoki` which is
different with `--bind-services` (as it provides a security provider as a
service and doesn't export API).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23514#discussion_r1946877904
