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
