Today, the value reported by the ActiveSetting event is what was last set (or the default value), regardless if the setting is valid or not.

When the setting system was designed for JDK 9, it was considered if the last value set, or what getValue() returns, should be used. I don't remember why we chose the last value, but one reason could have been to reduce overhead since getValue() must happen in an AccessControl context.

Now, I think it would make the setting system more consistent if we use getValue(). The method is already used to get the default value and the Security Manager is going away. The name of the event is "active setting" not "specified setting" so it would be more accurate. There is also a caching mechanism so if the same value is set twice, there will be no call to getValue(). The call to getValue() can also happen at the same time as setValue() so there is no additional context that needs to be used.

There is an ongoing effort to clean up the settings system (for invalid values), see JDK-8335907, but I think it makes sense to do this change separately to track regressions.

All tests pass with a change to getValue(), so the impact to existing code is likely low. If a user does:

    $ java -XX:StartFlightRecording:jdk.JavaMonitorWait#stackTrace=foo ...

we would before the change get:

    jdk.ActiveSetting {
      startTime = 16:40:59.040 (2024-07-12)
      id = 89
      name = "stackTrace"
      value = "foo"
    }

and after the change:

    jdk.ActiveSetting {
      startTime = 16:40:59.040 (2024-07-12)
      id = 89
      name = "stackTrace"
      value = "false"
    }