RFC: Introduce JDK property jdk.patched for indicating --patch-module at runtime

[Severin Gehwolf]

On Wed, 2024-11-13 at 07:35 +0000, Alan Bateman wrote:
> On 13/11/2024 03:44, David Holmes wrote:
> > 
> > The VM already sets properties like
> > 
> >  jdk.module.patch.N=<...>
> > 
> > when processing --patch-mods. Doesn't that suffice if all you need is 
> > a boolean flag to indicate any patching has occurred?
> > 
> > I would have thought you'd like to know which module has been patched, 
> > or to be able to ask if a given module has been patch - in which case 
> > an actual API method on java.lang.Module would seem reasonable. Or is 
> > this an area where module patching is only part of the implementation 
> > of Modules in the JDK, not part of the actual Java SE Module 
> > specification?
> 
> It's very JDK specific and --patch-module is complex due to being a 
> repeated option. The jdk.module.patch.<N> properties are the internal
> way to communicate the values provide to --patch-module during startup. 
> The properties are removed to avoid wider parts of the system having a 
> dependency on its private protocol.

Yes. Also a `jdk.patched` boolean property would be more generic and
wouldn't leak any details. A use-case of such a property can be seen
in:

https://github.com/openjdk/jdk/pull/22037

It currently needs to jump through hoops (using VM.getSavedProperties),
which is internal API. A more generic property would satisfy this use-
case without needing to expose jdk.internal.misc to jdk.jlink from
java.base. I.e. if at least one internal jdk.module.patch.<N> is
present, the public property would be true.

Thanks,
Severin