On Fri, 20 Feb 2026 11:13:27 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: > > update bugid Marked as reviewed by kevinw (Reviewer). Hi Kieran - At this point I would go with what you have here, the new standalone jcmd VM.security_properties. I'm not sure how confusing the original shared command would be, but this needs to progress. 8-) Just to be complete: Back in the JBS issue there is also the suggestion of "Security.properties" as they are not technically "in the VM". A new "Security" category in jcmd does not cost us anything, although it might feel like a leap. But "VM.system_properties" are similarly fetched from Java's System.getProperties(). If the "VM" category is where you go for properties already, VM.security_properties can't be that bad. ------------- PR Review: https://git.openjdk.org/jdk/pull/29124#pullrequestreview-3943512401 PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-4054587320
