Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8141856 | emb-9 | Derek White | P4 | Resolved | Fixed | team |
In this bug I'm talking about "regular" -XX options ("-XX:+Foo", "-XX:-Foo", "-XX:Foo=bar", etc) that have (or used to have) a matching variable in globals.hpp.
The "obsolete_jvm_flags" data structure was added to arguments.cpp to automatically deprecate or disable obsolete -XX options as the JDK version increases. But this doesn't handle other common kinds of options - in particular "alias" and "handled but deprecated" options.
A taxonomy of options:
Dead: Any use of the option results in an error***.
Obsolete & Deprecated: Any use of the option results in a warning, and the option setting is ignored.
Obsolete: Any use of the option is silently ignored.
Handled & Deprecated: Any use of the option results in a warning, and the option setting is used.
Handled: Regular, everyday option.
Aliased & Deprecated: Any use of the option results in a warning to use another option, and the other option is set to the value specified.
Aliased: Any use of the option sets the value of another option. No warning.
Currently the "obsolete_jvm_flags" handles the "Dead" and "Obsolete & Deprecated" cases, and normal argument processing covers "Handled".
We need a mechanism to handle "Aliased & Deprecated", and "Handled & Deprecated" options that will automatically transition an option to "Dead" in a specified JDK version. The mechanism should also support "Aliased" options. These two enhancements will remove a lot of custom option processing in Arguments::parse_each_vm_init_arg() and replace the need for check_deprecated_gc_flags().
This mechanism will enable the eventual removal of obsolete command line options that can otherwise linger in the code base for more than a decade. See for example bug 8061611 https://bugs.openjdk.java.net/browse/JDK-8061611
The "obsolete_jvm_flags" data structure was added to arguments.cpp to automatically deprecate or disable obsolete -XX options as the JDK version increases. But this doesn't handle other common kinds of options - in particular "alias" and "handled but deprecated" options.
A taxonomy of options:
Dead: Any use of the option results in an error***.
Obsolete & Deprecated: Any use of the option results in a warning, and the option setting is ignored.
Obsolete: Any use of the option is silently ignored.
Handled & Deprecated: Any use of the option results in a warning, and the option setting is used.
Handled: Regular, everyday option.
Aliased & Deprecated: Any use of the option results in a warning to use another option, and the other option is set to the value specified.
Aliased: Any use of the option sets the value of another option. No warning.
Currently the "obsolete_jvm_flags" handles the "Dead" and "Obsolete & Deprecated" cases, and normal argument processing covers "Handled".
We need a mechanism to handle "Aliased & Deprecated", and "Handled & Deprecated" options that will automatically transition an option to "Dead" in a specified JDK version. The mechanism should also support "Aliased" options. These two enhancements will remove a lot of custom option processing in Arguments::parse_each_vm_init_arg() and replace the need for check_deprecated_gc_flags().
This mechanism will enable the eventual removal of obsolete command line options that can otherwise linger in the code base for more than a decade. See for example bug 8061611 https://bugs.openjdk.java.net/browse/JDK-8061611
- backported by
-
JDK-8141856 Enhance command line processing to manage deprecating and obsoleting -XX command line arguements
-
- Resolved
-
- relates to
-
JDK-8067818 [TESTBUG] Add regression tests for JDK-8061611
-
- Resolved
-
-
JDK-8029942 Update VERSION_MAJOR for JDK 10
-
- Resolved
-
-
JDK-8061611 Remove deprecated command line flags
-
- Resolved
-