jmods-less jlinking prototype

[Alan Bateman]

On 07/07/2023 12:40, Severin Gehwolf wrote:
> :
>>>> For the native libs then I think the ModuleFinder can detect that the
>>>> hashes have changed. There's a choice here on whether it just warns or
>>>> fails. As you know, the only plugin that modifies native libs right now
>>>> is the debug symbol stripping. There is also the VM selection plugin but
>>>> that just works as a filter.
>> Sounds good. I'll go for producing warnings first.
> FYI: I've moved this to:
> https://bugs.openjdk.org/browse/JDK-8311302
>

Okay, I think we can continue the discussion there.  There are few 
aspects to this that will require discussion. For example, it might be 
better to limit this to a single hop to avoid divergence from the 
contents of the original modules, which will happen when plugins strip 
resources, e.g. --include-locales and specify a subset of the locales to 
include. Limiting it to a single hop isn't too different that not 
including the jdk.jlink module or not specifying the 
--keep-package-module to copy the packaged modules into the target 
image. I've looked at dozens of scripts that use jlink and I don't think 
I've seen usages of --keep-packages-modules so all these usages are 
already single hop. There is also the question on whether to warn or 
fail when user editable configuration has been modified. When its 
security or crypto config then it might be better to fail, so maybe that 
would be the default policy with an option to do what you have and emit 
a warning.

In passing, I think drop the phrase "jmod-less". In its place, I think 
the mental model should be that the current run-image is the last 
element in the module path, the jmods directory is the second last 
element, if that makes sense. I think you are close to that already with 
the --verbose output where a jrt URI will be printed when the module 
comes from the current run-time image.

-Alan