From openjdk-serviceability-dev  Wed Nov 30 16:56:23 2022
From: Kevin Walls <kevinw () openjdk ! org>
Date: Wed, 30 Nov 2022 16:56:23 +0000
To: openjdk-serviceability-dev
Subject: Re: RFR: 8297794: Deprecate JMX Management Applets for Removal [v2]
Message-Id: <3FHzBgGrbNsXw_-0AVjsVEu9F7Dozk7MS-iKniSNlwo=.86a55a56-0925-4d66-adff-63ad340d38c3 () github ! com>
X-MARC-Message: https://marc.info/?l=openjdk-serviceability-dev&m=166982699832151

On Wed, 30 Nov 2022 16:08:23 GMT, Alan Bateman <alanb@openjdk.org> wrote:

>> 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).
>
> It's not public so not part of the API, but you may be right that it would reduce the number of places where the warning needs to be suppressed.

I tested making the class MLetParser itself @Deprecated in the same way, and it still needs a @SuppressWarnings annotation on the parse(url) method, or it produces 3 warnings regarding use of MLetContent.
I don't mind adding the deprecation note to these two classes to make it clear that these non-public classes are also on the way out.

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

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