Hi Chia-Ping, You are right that @SuppressWarnings is just a temporary workaround. The fundamental issue remains: in version 5.0, when constructors become package-private, internal Kafka code in other packages (KafkaProducer, KafkaAdminClient, etc.) will lose access.
Given these constraints, Sean's minimal public Time interface seems to be the cleanest solution. Thanks. On Tue, Jul 21, 2026 at 8:25 AM Chia-Ping Tsai <[email protected]> wrote: > hi Siddhartha > > I might be misunderstanding the approach of this PR. The > @SuppressWarnings("deprecation") annotation is just a temporary workaround > for now, right? We will eventually face the same issue in version 5.0: how > to create a Metrics instance with a specific Time object from another > package. > > Best, > Chia-Ping > > On 2026/07/20 21:34:15 Siddhartha Devineni wrote: > > Hi Chia-Ping and Sean, > > > > To clarify the earlier discussion, after further investigation, "Metrics" > > doesn't call any "Time" methods directly, rather it just stores and > passes > > it to internal components (this.time = time on line 174). > > > > This means no officially public Javadoc class actually needs to call any > > "Time" methods. > > > > So, we could simply: > > 1. Deprecate Time-accepting constructors in "Metrics" and "KafkaStreams" > > 2. Keep "Time" as internal API > > 3. No new public interface needed > > > > I have already created a PR implementing this approach after > > withdrawing the KIP > > > > https://github.com/apache/kafka/pull/22689 > > > > WDYT? > > > > Thanks and Best regards, > > Siddhartha > > > > On Mon, Jul 20, 2026 at 8:02 PM Chia-Ping Tsai <[email protected]> > wrote: > > > > > hi Alieh > > > > > > We could keep discussing on this mail thread. > > > > > > The solution provided by Sean is pretty good. Except for KafkaStreams, > the > > > others only use the `milliseconds` so we could have a new simple > interface > > > Time, which could be located at org.apache.kafka.common, to replace > origin > > > Time-accepting constructor > > > > > > Best, > > > Chia-Ping > > > > > > On 2026/07/20 14:27:00 Alieh Saeedi via dev wrote: > > > > Hi > > > > > > > > Why is the KIP marked as withdrawn if the discussion is still > ongoing in > > > > the same thread? > > > > > > > > -Alieh > > > > > > > > On Mon, Jul 20, 2026 at 3:31 PM Sean Quah via dev < > [email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I was hoping we could avoid making Time public. Failing that, is it > > > > > possible to reduce the public API surface further? I looked at > Metrics > > > > > before and it only wanted the wall clock (milliseconds()). Perhaps > > > > > the other constructors are the same? > > > > > We could perhaps have a very simple public Time interface only > exposing > > > > > milliseconds (effectively a wall clock interface) and an internal > Time > > > > > interface which extends it with other methods. > > > > > > > > > > Thanks, > > > > > Sean > > > > > > > > > > On Mon, Jul 20, 2026 at 8:51 AM Chia-Ping Tsai < > [email protected]> > > > > > wrote: > > > > > > > > > > > hi all, > > > > > > > > > > > > I re-read the constructors, and I think deprecating the > > > time-accepting > > > > > > constructors will introduce huge changes to the codebase. > > > > > > > > > > > > Maybe we could just make Time public with a few methods, such as > > > > > > milliseconds, nanoseconds, and sleep. Since Timer is not public, > we > > > could > > > > > > add a helper method to Timer, like Timer.create(Time, ...), to > > > replace > > > > > > Time#timer(). > > > > > > > > > > > > WDYT? > > > > > > > > > > > > On 2026/04/23 20:57:19 Siddhartha Devineni wrote: > > > > > > > Hi Chia-Ping, Kirk and Matthias, > > > > > > > > > > > > > > @Chia-Ping: You were right - after investigating, Time doesn't > > > need to > > > > > be > > > > > > > public. > > > > > > > > > > > > > > @Kirk: You are right - the OAuth examples are instantiated via > > > > > > reflection, > > > > > > > not direct user code. > > > > > > > > > > > > > > @Matthias: Good points. I investigated whether Metrics can be > > > changed > > > > > to > > > > > > > not expose Time. > > > > > > > > > > > > > > Findings: > > > > > > > > > > > > > > - new Metrics() - users call this (internally uses Time.SYSTEM) > > > > > > > - new Metrics(Time time) and other variants - only called by > > > internal > > > > > > Kafka > > > > > > > code (KafkaProducer, KafkaAdminClient, etc) and tests > > > > > > > > > > > > > > Proposed approach: > > > > > > > > > > > > > > - Withdraw KIP-1311 (Make Time public) > > > > > > > - Create JIRA: "Deprecate Time-accepting constructors" > > > > > > > - Deprecate Time constructors in both KafkaStreams and Metrics: > > > > > > > - KafkaStreams(Topology, Properties, Time) > > > > > > > - KafkaStreams(Topology, StreamsConfig, Time) > > > > > > > - KafkaStreams(Topology, Properties, KafkaClientSupplier, > > > Time) > > > > > > > - Metrics(Time) > > > > > > > - Metrics(MetricConfig, Time) > > > > > > > - Metrics(MetricConfig, List<MetricsReporter>, Time) > > > > > > > - (and other Metrics variants accepting Time) > > > > > > > - In version 5.0, make these constructors package-private > > > > > > > - Internal Kafka code continues using them > > > > > > > > > > > > > > Result: Time remains internal. > > > > > > > > > > > > > > Does this approach work? If so, I'll withdraw KIP-1311 and > create > > > the > > > > > > JIRA. > > > > > > > > > > > > > > Thank you, > > > > > > > Siddhartha > > > > > > > > > > > > > > On Tue, Apr 21, 2026 at 5:22 AM Matthias J. Sax < > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Thanks for the KIP. I am not sure if I understand why > > > > > > `KafkaStreamsMock` > > > > > > > > would be anything public? > > > > > > > > > > > > > > > > Also, why would we put it into some new `...test...` > package? If > > > we > > > > > > > > change the package, we need to have `protected` access, > which is > > > > > > already > > > > > > > > "semi-public"... > > > > > > > > > > > > > > > > If we want to keep `Time` internal, we would eventually make > the > > > > > > > > constructors that are marked deprecated, package-private, > what > > > allows > > > > > > us > > > > > > > > to add `org.apache.kafka.streams.KafkaStreamsMock` (same > package > > > > > name, > > > > > > > > but int `test/` module) to still use these constructors, and > the > > > > > > > > corresponding unit test would use the new mock-factory > instead of > > > > > > > > calling `new`? > > > > > > > > > > > > > > > > For this case, the KIP does not need to mention anything > about > > > > > > > > `KafkaStreamsMock` as it's an helper in our `test/` module > only, > > > but > > > > > > not > > > > > > > > public API. -- If we want, we can still mention this plan on > the > > > KIP, > > > > > > > > but atm the KIP is written in a way as if `KafkaStreamsMock` > > > would > > > > > > > > become public API, but to my understanding it should be an > > > > > impl/testing > > > > > > > > details only? > > > > > > > > > > > > > > > > Or did I misunderstand something? > > > > > > > > > > > > > > > > > > > > > > > > Also wondering, if we could also change `Metrics` in a way, > that > > > we > > > > > > > > would not need to make `Time` public to begin with? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > > On 4/20/26 4:53 PM, Kirk True wrote: > > > > > > > > > Hi Siddhartha, > > > > > > > > > > > > > > > > > > The OAuth examples use Time in their constructors for unit > > > tests. > > > > > > > > They're not intended to be instantiated by any user code > since > > > > > they're > > > > > > in > > > > > > > > an internals package. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Kirk > > > > > > > > > > > > > > > > > > On Wed, Apr 15, 2026, at 8:52 AM, Siddhartha Devineni > wrote: > > > > > > > > >> Hi Chia-Ping, > > > > > > > > >> > > > > > > > > >> Sorry that i didn't mention the following examples in the > KIP > > > > > > earlier. > > > > > > > > >> Now, I have updated the KIP with the following public > packages > > > > > > examples, > > > > > > > > >> where "Time" is exposed in the public constructors: > > > > > > > > >> > > > > > > > > >> // couple of examples from multiple > > > > > > > > >> "org.apache.kafka.common.metrics.Metrics.java" > constructors > > > > > > > > >> public Metrics(Time time) {} > > > > > > > > >> public Metrics(MetricConfig defaultConfig, Time time) {} > > > > > > > > >> > > > > > > > > >> // in the public package > > > > > > "org.apache.kafka.common.security.oauthbearer" > > > > > > > > >> public JwtBearerJwtRetriever(Time time) {} > > > > > > > > >> public ClientCredentialsJwtRetriever(Time time) {} > > > > > > > > >> > > > > > > > > >> Now, it should be clear. > > > > > > > > >> Thanks for your time. > > > > > > > > >> > > > > > > > > >> Best regards, > > > > > > > > >> Siddhartha > > > > > > > > >> > > > > > > > > >> On Tue, Apr 14, 2026 at 11:14 AM Chia-Ping Tsai < > > > > > [email protected] > > > > > > > > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >>> hi Siddhartha > > > > > > > > >>> > > > > > > > > >>> Thanks for this KIP. > > > > > > > > >>> > > > > > > > > >>> What is the exact benefit of exposing Time as a public > API? > > > Since > > > > > > this > > > > > > > > KIP > > > > > > > > >>> proposes deprecating KafkaStreams(Topology, Properties, > > > Time), it > > > > > > seems > > > > > > > > >>> there are no public interfaces relying on it anymore. > > > > > > > > >>> > > > > > > > > >>> Thus, it should be fine to just keep Time as an internal > API, > > > > > > right? > > > > > > > > >>> > > > > > > > > >>> Best, > > > > > > > > >>> Chia-Ping > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> Siddhartha Devineni <[email protected]> 於 > > > > > 2026年4月7日週二 > > > > > > > > >>> 下午2:19寫道： > > > > > > > > >>> > > > > > > > > >>>> Apologies, as I forgot to add the link to the KIP: > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406623925__;!!Ayb5sqE7!o-ar2zzpALvIzp5wF7s2E77bUw9C8CxXLU1JxqxsiiliVfUFzl_M8gIOcFoy3T1nFx5L78W0vA8d7XV_enMH$ > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> On Tue, Apr 7, 2026 at 9:13 AM Siddhartha Devineni < > > > > > > > > >>>> [email protected]> wrote: > > > > > > > > >>>> > > > > > > > > >>>>> Hello everyone, > > > > > > > > >>>>> > > > > > > > > >>>>> I would like to start a discussion on [DISCUSS] > KIP-1311: > > > Make > > > > > > > > >>> Time/Timer > > > > > > > > >>>>> public API. > > > > > > > > >>>>> > > > > > > > > >>>>> Following KIP-1247 (Make Bytes part of public API), the > > > Time > > > > > > > > interface > > > > > > > > >>>> and > > > > > > > > >>>>> Timer class are the next candidates from > > > > > > > > >>> "org.apache.kafka.common.utils" > > > > > > > > >>>> to > > > > > > > > >>>>> be made officially public. Time is currently exposed > > > through > > > > > > public > > > > > > > > >>> APIs > > > > > > > > >>>>> (e.g., in clients, KafkaStreams constructors, etc) but > not > > > > > > officially > > > > > > > > >>>>> designated as a public API. > > > > > > > > >>>>> > > > > > > > > >>>>> An earlier version of this KIP explored splitting Time > into > > > > > > focused > > > > > > > > >>>>> interfaces (Clock, MonotonicClock, etc.), but this > would > > > > > require > > > > > > > > >>>> rewriting > > > > > > > > >>>>> thousands of method signatures across the Kafka > codebase. > > > The > > > > > > simpler > > > > > > > > >>>>> approach of making Time public as-is seems more > > > appropriate to > > > > > > avoid > > > > > > > > >>>>> breaking changes. > > > > > > > > >>>>> > > > > > > > > >>>>> Looking forward to your feedback. > > > > > > > > >>>>> > > > > > > > > >>>>> Thank you, > > > > > > > > >>>>> Siddhartha > > > > > > > > >>>>> > > > > > > > > >>>> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
