Hi Chia,
Quick follow-up -- I put up a small draft PoC to make this concrete:
https://github.com/apache/kafka/pull/22758
It shows the three cases for these internal-but-public classes; the PoC has
code for the first two (I left the big one, Utils, out to keep it small):
ByteBufferInputStream -- moved to an internals package, with the old public
class left as a thin @Deprecated(since = "4.4", forRemoval = true) wrapper that
extends the internal one. Existing code still compiles and now gets a warning;
Kafka's own callers switch to the internal class.
ProducerIdAndEpoch -- here only as an example of the in-place case: deprecated
where it is (not moved). Its callers add @SuppressWarnings("deprecation"); the
@Deprecated would be removed again in 5.0.0, when the policy already treats the
class as unsupported.
LoggingSignalHandler -- no code at all. Classes that almost no one imports
externally (this one has ~5 on GitHub) are just left to the policy: a warning
would help no one, and adding @Deprecated still has a maintainer cost (the
caller changes from the first two cases), so it is not worth it.
Which approach fits which class is a maintainer decision.
Thanks,
Eric
