Discussion: OpenJ9 Policy for deprecating external or documented controls

[dsouzai]

I'm opening this issue to start a discussion on defining a policy for how external controls (JVM options, APIs, etc), can be deprecated. For example, before letting #12503 get too far along, it would be beneficial for OpenJ9 to have a defined procedure for how deprecation should be handled. This procedure should take into account (at least):

• Current Stakeholders usage
• Overlap period
• Release schedule
• Documentation updates
• Dealing with deprecation because of OMR
• Dealing with deprecation that needs changes to OMR

Once a community approved procedure is defined, issues like #12503 can be tackled.

[pshipton]

I suggest deprecation needs to occur in a new Java release, say Java 17, and then the item can be removed in the following release, i.e. Java 18. It can only be removed for Java 18 and still needs to work for Java 8 & 11 until those versions are no longer supported.

[klangman]

I would agree with Peter when it comes to supported documented options. For completely undocumented options where there is very limited usage we can allow immediate changes (i.e. JIT env vars). For unsupported, only use as directed type, debugging or work-around options I think we need some happy medium. Maybe a stderr warning when the option is used for some period of time before the options is removed.

[dsouzai]

Closing this given #16419.