On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell <[email protected]> wrote:
>> The goal of this PR is to add a means of exposing security properties at >> runtime to aid the debugging security related issues/misconfigurations etc. >> Currently, only initial security properties set at start up can be exposed >> via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which >> enables developers to print either the current system properties or security >> properties of a running Java process via command-line arguments (-system or >> -security). To avoid clutter within the jcmd command list, the old >> `VM.system_properties` command is hidden, but not removed so will not break >> existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional > commit since the last revision: > > hide command > Security properties are a somewhat niche set of non-system properties for the > security/crypto area. They can't be set on the command line, need to use > -Djava.security.properties== to locate a properties file to augment the > security properties defined in java.security. So very confusing to developers > and maybe it's time to think about whether security properties make sense in > 2026. > Should this PR be put on hold until such a disccusion takes place or maybe that would be something a little further down the line? > As regards the proposal then my initial reaction is to keep it separate, > meaning a security_properties rather than properties command. My initial patch added a seperate command `VM.security_properties` but I merged the two following a suggestion reduce clutter in the the `jcmd <PID> help` output. Happy to revert to a seperate command if we proceed with this and there is a preference to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3728531839
