Hi all, Thank you for the feedback.
@Sean, I understand your concern about "Time" not being suitable for a public API in its current state. Could you elaborate on what specific issues make it a "dumping ground"? Regarding your suggestion to exclude the Streams constructors accepting "Time" from the public API - I want to clarify the implications: The constructor KafkaStreams(Topology, Properties, Time) is currently public and has been available for several releases. Making it non-public or removing it would be a breaking change that would affect any users currently using this constructor. What do you have in mind? 1. Deprecate the constructor now and remove it in a future major version, or 2. Make it package-private (which would break existing code immediately)? @Kirk, Thank you for pointing that out. You're absolutely right that making "Time" public would require making "Timer" public as well, since Time.timer() returns Timer objects. This does expand the scope considerably. Given this expanding scope and Sean's concerns about the Time API design, would it make sense to split this KIP into two parts or create a separate KIP for the "Time" API and its implications? Best regards, Siddhartha On Tue, Dec 16, 2025 at 6:18 AM Kirk True <[email protected]> wrote: > 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 > > > > > >
