search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 720 forks source link

Discussion: OpenJ9 Policy for deprecating external or documented controls #12596

Open dsouzai opened 3 years ago

dsouzai commented 3 years ago

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 https://github.com/eclipse-openj9/openj9/issues/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):

Once a community approved procedure is defined, issues like https://github.com/eclipse-openj9/openj9/issues/12503 can be tackled.

pshipton commented 3 years ago

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 commented 3 years ago

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.