Summary

Add a new system property jdk.patched when the runtime has been patched with --patch-module.

Problem

With JEP 493 the possibility of linking a custom runtime from the current run-time image has been introduced. This is problematic when the runtime itself has been patched with --patch-module as non-standard classes might populate to the resulting linked runtime. It is therefore desired to detect patched runtimes before a link from the run-time image is being performed in order to abort the link.

It's also useful to be able to detect a patched runtime by means of a JDK specific system property for serviceability purposes.

Solution

Add a read-only, JDK specific, boolean property, jdk.patched, which is set to true if one or more of --patch-module switches have been used on the java launcher.

An alternative solution for the jlink specific use-case has been considered: Use the internal saved properties, jdk.module.patch.<N>. This has the drawback of needing to export the internal VM class to the jdk.jlink module. Using a public, JDK-specific, system property has the advantage of it being available to serviceability tools and not needing to expose saved properties from the JVM.

Specification

When the --patch-module parsing is successful in arguments.cpp of HotSpot, set the externally visible system property to true. Do it only in that case, similar to how jdk.module.path are only set if the --module-path option have been set.

PR with this change is here: https://github.com/openjdk/jdk/pull/22277