It was on pause during the summer - vacations took priority. I will check your feedback this week and give an update.
Ray On Thursday, 22 August 2024 at 20:20, Matthias J. Sax <mj...@apache.org> wrote: > What is the status of this KIP? > > On 7/30/24 7:36 PM, Matthias J. Sax wrote: > > > Thanks a lot for the KIP > > > > Ray > > > > ! > > > > It seems to be a good improvement to make using KS with Clojure more > > seamless. > > > > However, I am not 100% sure if all listed interfaces make sense? > > > > (100) GlobalKTable: it's basically a sibling to `KStream`, and `KTable` > > interfaces, but users would never implemented it, and thus I think it > > won't make much sense to add the annotation. Playing devils advocate, it > > could even be "harmful" as it might provide a wrong signal to users that > > this interface would be intended to be implemented by them. > > > > (200) NamedOperation: this is some helper interface that user also won't > > need to implement. I am less worried about being harmful (as I am for > > GlobalKTable), but I also don't see much of an advantage. > > > > (300) TransformerSupplier and ValueTransformerSupplier: both are going > > to be deprecate with 4.0, which is only a side cleanup anyway. Both can > > only be used with `KStream.transform()`, `.flatTransform()`, > > `.transformValues()` and `.flatTransformValues()` and all four method > > will be removed in 4.0 rending both interface practically useless. -- No > > damage to include them, but also not useful. > > > > (400) ProcessorSupplier and Processor: there is currently two interfaces > > with each name, the old and already deprecated interfaces > > `...processor.Processor[Supplier]` and the new > > `...processor.api.Processor[Supplier]`. The KIP should be explicit and > > say `api.Proceccor[Supplier]` as only the new interfaces have annotation > > already, but not the old ones. - The old interfaces do also not need to > > be updated IMHO, as will we remove both with 4.0, too. > > > > (410) There is also two interfaces `...processor.ProcessorContext` and > > `...processor.api.ProcessorContext`. Both are still in used, and thus > > the KIP should mention both explicitly. > > > > (500) I am not sure if the KIP need to explicitly list all interface it > > does not update... It's a long list and it might be easier to read the > > KIP if omitted? > > > > (600) There is some other interface/abstract-classes which might benefit > > from the annotation, too: > > > > - org.apache.kafka.streams.errors: > > > > DeserializationExceptionHandler (does not qualify now, but we could > > include it in the KIP and file a follow up ticket for the future to add > > it, when we remove the deprecated method? -- This would avoid the need > > for another KIP in the future) > > StreamsUncaughtExceptionHandler > > > > - org.apache.kafka.streams.processor.api: > > > > ContextualFixedKeyProcessor > > ContextualProcessor > > > > - org.apache.kafka.streams.processor: > > > > CommitCallback > > Punctuator > > StateRestoreCallback > > StreamPartitioner (there is already a open PR to remove the > > deprecate method so it will qualify in 4.0 release) > > TimestampExtractor > > TopicNameExtractor > > > > -Matthias > > > > On 7/29/24 12:47 AM, Ray McDermott wrote: > > > > > These annotations assist with clarifying the purpose of the interface, > > > as well as assisting interop with non-Java JVM languages. > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1072%3A+Add+@FunctionalInterface+annotation+to+Kafka+Streams+SAM+methods > > > > > > Comments welcome > > > > > > Thanks > > > > > > Ray
