On Thu, 2 Jul 2026 13:23:52 GMT, Kieran Farrell <[email protected]> wrote:
>> src/hotspot/share/services/diagnosticCommand.hpp line 874: >> >>> 872: return "Print information similar to -XshowSettings, e.g. " >>> 873: "'VM.show_settings locale' or 'VM.show_settings >>> security:tls'."; >>> 874: } >> >> For the help, do we document all the options here, or say "See 'java -X' for >> the list of -XshowSettings options". >> >> Similarly, in ShowSettingsDCmd::execute() do we need to verify all the >> section names, or can we leave that to the existing implementation? >> If we can avoid maintaining this list in more than one place, that would be >> great. > > Updating the help to direct to using java -X to get the options list sounds > like a good idea. > > However we cant leave validation of the section names up to the existing > implementation in `LauncherHelper` as `validateOption()` currently calls > `abort()` for invalid options, which calls `System.exit(1)` which would shut > down the live VM on which this jcmd would be used. One option would be to > move the jcmd validation to `showSettingsBytes` of the `LauncherHelper` so at > least both lists of valid sections are kept in the one class? Yes that is unfortunate. We need to know that the jcmd cannot possibly cause an exit, so the verification in the diagnostic framework side has to be complete. 8-) LauncherHelper's showSettings calls validateOption(), and looks like the only caller, so maybe it's not too bad to make validateOption() throw and never abort/exit, and have showSettings itself conditionally abort/exit based on that. Then the jcmd or showSettingsBytes can call validateOption and check for an exception. If that works out too ugly then yes whatever you can do to group the lists together will help them stay in sync. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31742#discussion_r3513625802
