RFR: 8297794: Deprecate JMX Management Applets for Removal

[Daniel Fuchs]

On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
> 
> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
> 
> More details in bug, and CSR JDK-8297795

I have the same remark as Alan - I believe an `@deprecated ` text is needed in the API documentation of the public exported classes that are deprecated. At the minimum something like:

* @deprecated This class is deprecated for removal. There is no replacement. 


I also see that you have chosen to add `@SuppressWarnings` in tests. Not sure what the rules are for the serviceability area - but usually it's fine to keep the deprecation warning in tests (that is: suppressing deprecation warnings in tests is usually optional).

src/java.management/share/classes/javax/management/loading/MLetObjectInputStream.java line 43:

> 41: class MLetObjectInputStream extends ObjectInputStream {
> 42: 
> 43:     @SuppressWarnings("removal")

Shouldn't `MLetObjectInputStream` be deprecated for removal too? I mean - if MLet was removed - would we need to keep that class? If it were deprecated for removal too then I suspect that there would be no need to suppress the warning here (and below).

src/java.management/share/classes/javax/management/loading/MLetParser.java line 156:

> 154:      * Scan an html file for {@literal <mlet>} tags.
> 155:      */
> 156:     @SuppressWarnings("removal")

Same remark here. This class should probably be deprecated for removal too.

-------------

PR: https://git.openjdk.org/jdk/pull/11430