Hi all,

Sean: which parts of the Time API are the most clunky? The waitForFuture() and 
waitObject() methods seem like they could be moved elsewhere, but the others 
seem OK. 

Siddhartha: because the Time API creates Timer objects, we'd need to promote 
Timer to the public API, too. 

Thanks,
Kirk

On Fri, Dec 12, 2025, at 7:12 AM, Sean Quah via dev wrote:
> Hi Siddhartha,
> 
> Thanks for the KIP! I'm okay making `Bytes` public. However, the `Time`
> interface is a bit of a dumping ground for time-related things and I would
> not be in favor of making it public in its current state.
> Is it possible to exclude the streams constructors accepting `Time`s from
> the public API instead?
> 
> Kind regards,
> Sean Quah
> 
> On Sun, Dec 7, 2025 at 1:53 PM Siddhartha Devineni <
> [email protected]> wrote:
> 
> > Hello Kafka Community,
> >
> > I would like to start a discussion on KIP-1247, which proposes to
> > officially make the "Bytes" and "Time" utils classes part of Kafka's public
> > API.
> >
> > *KIP Link:*
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1247%3A+Make+Bytes+and+Time+utils+classes+part+of+the+public+API
> >
> > *Background:*
> >
> > Currently, "org.apache.kafka.common.utils.Bytes" and
> > "org.apache.kafka.common.utils.Time" are exposed through numerous public
> > API interfaces in Kafka Streams and other components, yet they are not
> > officially designated as public API since the utils package is not included
> > in Javadoc generation.
> >
> > This creates confusion for users who cannot determine if these classes are
> > officially supported, and causes broken Javadoc references.
> >
> > *Proposal:*
> >
> > This KIP proposes to:
> >
> >    1. Include "Bytes" and "Time" in Javadoc generation, officially making
> >    them part of the public API
> >    2. Move other internal utility classes to an "internals" subpackage to
> >    prevent similar issues in the future
> >
> >
> >
> > *Impact:*This change has no compatibility impact - all classes remain in
> > their current locations and no user code changes are required.
> >
> > You can find more details in the attached KIP link.
> > Looking forward to your thoughts.
> >
> > Thank you.
> >
> > Best regards.
> > Siddhartha
> >
> 

Reply via email to