From openjdk-serviceability-dev Wed Nov 30 13:56:07 2022 From: Daniel Fuchs Date: Wed, 30 Nov 2022 13:56:07 +0000 To: openjdk-serviceability-dev Subject: Re: RFR: 8297794: Deprecate JMX Management Applets for Removal Message-Id: X-MARC-Message: https://marc.info/?l=openjdk-serviceability-dev&m=166981656725141 On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls 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 } 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