On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls <[email protected]> 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
