Oh, ok. I have done that. Just didn't know that it was necessary. -Yuriy
On Fri, Jul 10, 2020 at 9:30 PM John Roesler <vvcep...@apache.org> wrote: > Ah, thanks Yuriy, > > Sorry if this wasn't clear, but _all_ public API changes have to > be explicitly included in the KIP. Can you just enumerate all > the contents of the new API? > > Thanks, > John > > On Fri, Jul 10, 2020, at 04:54, Yuriy Badalyantc wrote: > > Hi, Matthias, > > > > It's not directly mentioned in the KIP, but I added all missing Java > > serdes. I mentioned it in the pull request description: > > https://github.com/apache/kafka/pull/8955 > > > > And also, this KIP originally was based on a pull request where I added > > missing java serdes :) https://github.com/apache/kafka/pull/8049 > > > > -Yuriy > > > > On Fri, Jul 10, 2020 at 3:36 AM Matthias J. Sax <mj...@apache.org> > wrote: > > > > > Yuriy, > > > > > > thanks for the KIP update. I have one follow up thought: I checked what > > > default Serdes we offer in the Java class > > > > > > `org.apache.kafka.common.serialization.Serdes` > > > > > > and I think it would be good if we could close the gap between the Java > > > and Scala code and add the missing Java Serdes in Scala, too. > > > > > > It seems we are missing `Short` (Java and Scala), `Void`, `UUID`, and > > > `ByterBuffer`. > > > > > > Can we add those in addition? > > > > > > > > > -Matthias > > > > > > On 7/8/20 6:45 AM, John Roesler wrote: > > > > Hi Yuriy, > > > > > > > > Once it seems like there’s general agreement in the discussion, you > can > > > start a voting thread. You can find examples on the mailing list of > what to > > > say in the first message. It’s basically just a message with the > subject > > > line changed from “[DISCUSS]...” to “[VOTE]...”, and then stating that > > > you’d like to start the vote. It’s nice to link to the kip document > again. > > > > > > > > The rules for the vote are at the top of the “Kafka Improvement > Process” > > > page, but you basically need 3 binding +1 votes and no binding -1 > votes. > > > You also need to wait at least three days from when you start the vote > > > before you can declare it accepted. There’s no upper time limit. > > > > > > > > If you’re unsure of who has a binding vote, it’s just the people > listed > > > on the Apache Kafka Committers page. > > > > > > > > If people are slow to vote, feel free to keep bumping the thread, > just > > > like with the discussion. > > > > > > > > Thanks again for getting involved! > > > > -John > > > > > > > > On Tue, Jul 7, 2020, at 01:51, Yuriy Badalyantc wrote: > > > >> So, what's next? It's my first KIP and I'm not familiar with all > > > processes. > > > >> > > > >> -Yuriy > > > >> > > > >> On Mon, Jul 6, 2020 at 1:32 AM John Roesler <vvcep...@apache.org> > > > wrote: > > > >> > > > >>> Hi Yuriy, > > > >>> > > > >>> Thanks for the update! It looks good to me. > > > >>> > > > >>> Thanks, > > > >>> John > > > >>> > > > >>> On Sun, Jul 5, 2020, at 03:27, Yuriy Badalyantc wrote: > > > >>>> Hi John. > > > >>>> > > > >>>> I updated the KIP. An old proposed implementation is now in the > > > rejected > > > >>>> alternatives. > > > >>>> > > > >>>> - Yuriy > > > >>>> > > > >>>> On Sun, Jul 5, 2020 at 12:03 AM John Roesler <vvcep...@apache.org > > > > > >>> wrote: > > > >>>> > > > >>>>> Hi Yuriy, > > > >>>>> > > > >>>>> I agree, we can keep them separate. I just wanted to make you > aware > > > of > > > >>> it. > > > >>>>> > > > >>>>> Thanks for the PR, it looks the way I expected. > > > >>>>> > > > >>>>> I just read over the KIP document again. I think it needs to be > > > >>> updated to > > > >>>>> the current proposal, and then we’ll be able to start the vote. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> John > > > >>>>> > > > >>>>> On Tue, Jun 30, 2020, at 04:58, Yuriy Badalyantc wrote: > > > >>>>>> Hi everybody! > > > >>>>>> > > > >>>>>> Looks like a discussion about KIP-513 could take a while. I > think we > > > >>>>> should > > > >>>>>> move forward with KIP-616 without waiting for KIP-513. > > > >>>>>> > > > >>>>>> I created a new pull request for KIP-616: > > > >>>>>> https://github.com/apache/kafka/pull/8955. It contains a new > > > >>>>>> `org.apache.kafka.streams.scala.serialization.Serdes` object > without > > > >>> name > > > >>>>>> clash. An old one was marked as deprecated. This change is > backward > > > >>>>>> compatible and it could be merged in any further release. > > > >>>>>> > > > >>>>>> On Wed, Jun 3, 2020 at 12:41 PM Yuriy Badalyantc < > lmne...@gmail.com > > > > > > > >>>>> wrote: > > > >>>>>> > > > >>>>>>> Hi, John > > > >>>>>>> > > > >>>>>>> Thanks for pointing that out. I expressed my thoughts about > > > >>> KIP-513 and > > > >>>>>>> its connection to KIP-616 in the KIP-513 mail list. > > > >>>>>>> > > > >>>>>>> - Yuriy > > > >>>>>>> > > > >>>>>>> On Sun, May 31, 2020 at 1:26 AM John Roesler < > vvcep...@apache.org> > > > >>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Hi Yuriy, > > > >>>>>>>> > > > >>>>>>>> I was just looking back at KIP-513, and I’m wondering if > there’s > > > >>> any > > > >>>>>>>> overlap we should consider here, or if they are just > orthogonal. > > > >>>>>>>> > > > >>>>>>>> Thanks, > > > >>>>>>>> -John > > > >>>>>>>> > > > >>>>>>>> On Thu, May 28, 2020, at 21:36, Yuriy Badalyantc wrote: > > > >>>>>>>>> At the current moment, I think John's plan is better than the > > > >>>>> original > > > >>>>>>>> plan > > > >>>>>>>>> described in the KIP. I think we should create a new > `Serdes` in > > > >>>>> another > > > >>>>>>>>> package. The old one will be deprecated. > > > >>>>>>>>> > > > >>>>>>>>> - Yuriy > > > >>>>>>>>> > > > >>>>>>>>> On Fri, May 29, 2020 at 8:58 AM John Roesler < > > > >>> vvcep...@apache.org> > > > >>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>>> Thanks, Matthias, > > > >>>>>>>>>> > > > >>>>>>>>>> If we go with the approach Yuriy and I agreed on, to > > > >>> deprecate and > > > >>>>>>>> replace > > > >>>>>>>>>> the whole class and not just a few of the methods, then the > > > >>>>> timeline > > > >>>>>>>> is > > > >>>>>>>>>> less of a concern. Under that plan, Yuriy can just write the > > > >>> new > > > >>>>> class > > > >>>>>>>>>> exactly the way he wants and people can cleanly swap over to > > > >>> the > > > >>>>> new > > > >>>>>>>>>> pattern when they are ready. > > > >>>>>>>>>> > > > >>>>>>>>>> The timeline was more significant if we were just going to > > > >>>>> deprecate > > > >>>>>>>> some > > > >>>>>>>>>> methods and add new methods to the existing class. That plan > > > >>>>> requires > > > >>>>>>>> two > > > >>>>>>>>>> implementation phases, where we first deprecate the existing > > > >>>>> methods > > > >>>>>>>> and > > > >>>>>>>>>> later swap the implicits at the same time we remove the > > > >>> deprecated > > > >>>>>>>> members. > > > >>>>>>>>>> Aside from the complexity of that approach, it’s not a > > > >>> breakage > > > >>>>> free > > > >>>>>>>> path, > > > >>>>>>>>>> as some users would be forced to continue using the > deprecated > > > >>>>> members > > > >>>>>>>>>> until a future release drops them, breaking their source > > > >>> code, and > > > >>>>>>>> only > > > >>>>>>>>>> then can they update their code. > > > >>>>>>>>>> > > > >>>>>>>>>> That wouldn’t be the end of the world, and we’ve had to do > the > > > >>>>> same > > > >>>>>>>> thing > > > >>>>>>>>>> in the past with the implicit conversations, but this is a > > > >>> much > > > >>>>> wider > > > >>>>>>>>>> scope, since it’s all the serdes. I’m happy with the new > plan, > > > >>>>> since > > > >>>>>>>> it’s > > > >>>>>>>>>> not only one step, but also it provides everyone a > > > >>> breakage-free > > > >>>>> path. > > > >>>>>>>>>> > > > >>>>>>>>>> We can still consider dropping the deprecated class in 3.0; > I > > > >>> just > > > >>>>>>>> wanted > > > >>>>>>>>>> to clarify how the timeline issue has changed. > > > >>>>>>>>>> > > > >>>>>>>>>> Thanks, > > > >>>>>>>>>> John > > > >>>>>>>>>> > > > >>>>>>>>>> On Thu, May 28, 2020, at 20:34, Matthias J. Sax wrote: > > > >>>>>>>>>>> I am not a Scale person, so I cannot really contribute > much. > > > >>>>>>>> However for > > > >>>>>>>>>>> the deprecation period, if we get the change into 2.7, it > > > >>> might > > > >>>>> be > > > >>>>>>>> ok to > > > >>>>>>>>>>> remove the deprecated classed in 3.0. > > > >>>>>>>>>>> > > > >>>>>>>>>>> It would only be one minor release in between what is a > > > >>> little > > > >>>>> bit > > > >>>>>>>> short > > > >>>>>>>>>>> (we usually prefer at least two minor released, better > > > >>> three), > > > >>>>> but > > > >>>>>>>> if we > > > >>>>>>>>>>> have a good reason for it, it might be ok. > > > >>>>>>>>>>> > > > >>>>>>>>>>> If we cannot remove it in 3.0, it seems there would be a > > > >>> 4.0 in > > > >>>>>>>> about a > > > >>>>>>>>>>> year(?) when ZK removal is finished and we can remove the > > > >>>>> deprecated > > > >>>>>>>>>>> code than. > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> -Matthias > > > >>>>>>>>>>> > > > >>>>>>>>>>> On 5/28/20 7:39 AM, John Roesler wrote: > > > >>>>>>>>>>>> Hi Yuriy, > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Sounds good to me! I had a feeling we were bringing > > > >>> different > > > >>>>>>>> context > > > >>>>>>>>>>>> to the discussion; thanks for sticking with the > > > >>> conversation > > > >>>>>>>> until we > > > >>>>>>>>>> got > > > >>>>>>>>>>>> it hashed out. > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> I'm glad you prefer Serde*s*, since having multiple > > > >>> different > > > >>>>>>>> classes > > > >>>>>>>>>> with > > > >>>>>>>>>>>> the same name leads to all kinds of trouble. "Serdes" > > > >>> seems > > > >>>>>>>> relatively > > > >>>>>>>>>>>> safe because people in the Scala lib won't be using the > > > >>> Java > > > >>>>>>>> Serdes > > > >>>>>>>>>> class, > > > >>>>>>>>>>>> and they won't be using the deprecated and non-deprecated > > > >>> one > > > >>>>> at > > > >>>>>>>> the > > > >>>>>>>>>>>> same time. > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Thank again, > > > >>>>>>>>>>>> -John > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> On Thu, May 28, 2020, at 02:21, Yuriy Badalyantc wrote: > > > >>>>>>>>>>>>> Ok, I understood you, John. I wasn't sure about kafka > > > >>>>> deprecation > > > >>>>>>>>>> policy > > > >>>>>>>>>>>>> and thought that the full cycle could be done with 2.7 > > > >>>>> version. > > > >>>>>>>>>> Waiting for > > > >>>>>>>>>>>>> 3.0 is too much, I agree with it. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> So, I think creating one more `Serdes` in another > > > >>> package is > > > >>>>> our > > > >>>>>>>> way. > > > >>>>>>>>>> I > > > >>>>>>>>>>>>> suggest one of the following: > > > >>>>>>>>>>>>> 1. `org.apache.kafka.streams.scala.serde.Serdes` > > > >>>>>>>>>>>>> 2. `org.apache.kafka.streams.scala.serialization.Serdes` > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> About `Serde` vs `Serdes`. I'm strongly against `Serde` > > > >>>>> because > > > >>>>>>>> it > > > >>>>>>>>>> would > > > >>>>>>>>>>>>> lead to a new name clash with the > > > >>>>>>>>>>>>> `org.apache.kafka.common.serialization.Serde`. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> - Yuriy > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> On Thu, May 28, 2020 at 11:12 AM John Roesler < > > > >>>>>>>> vvcep...@apache.org> > > > >>>>>>>>>> wrote: > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Hi Yuriy, > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Thanks for the clarification. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> I guess my concern is twofold: > > > >>>>>>>>>>>>>> 1. We typically leave deprecated methods in place for at > > > >>>>> least a > > > >>>>>>>>>> major > > > >>>>>>>>>>>>>> release cycle before removing them, so it would seem > > > >>> abrupt > > > >>>>> to > > > >>>>>>>> have a > > > >>>>>>>>>>>>>> deprecation period of only one minor release. If we > > > >>> follow > > > >>>>> the > > > >>>>>>>> same > > > >>>>>>>>>> pattern > > > >>>>>>>>>>>>>> here, it would take over a year to finish this KIP. > > > >>>>>>>>>>>>>> 2. It doesn’t seem like there is a nonbreaking > > > >>> deprecation > > > >>>>> path > > > >>>>>>>> at > > > >>>>>>>>>> all if > > > >>>>>>>>>>>>>> people enumerate their imports (if they don’t use a > > > >>>>> wildcard). > > > >>>>>>>> In > > > >>>>>>>>>> that > > > >>>>>>>>>>>>>> case, they would have no path to implicitly use the > > > >>> newly > > > >>>>> named > > > >>>>>>>>>> serdes, and > > > >>>>>>>>>>>>>> therefore they would have no way to avoid continuing to > > > >>> use > > > >>>>> the > > > >>>>>>>>>> deprecated > > > >>>>>>>>>>>>>> ones. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Since you mentioned that your reason is mainly the > > > >>>>> preference > > > >>>>>>>> for > > > >>>>>>>>>> the name > > > >>>>>>>>>>>>>> “Serde” or “Serdes”, can we explore just using one of > > > >>> those? > > > >>>>>>>> Would > > > >>>>>>>>>> it cause > > > >>>>>>>>>>>>>> some kind of conflict to use > > > >>>>>>>> org.apache.kafka.streams.scala.Serde or > > > >>>>>>>>>> to use > > > >>>>>>>>>>>>>> Serdes in a different package, like > > > >>>>>>>>>>>>>> org.apache.kafka.streams.scala.implicit.Serdes? > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> I empathize with this desire. I faced the same dilemma > > > >>> when > > > >>>>> I > > > >>>>>>>> wanted > > > >>>>>>>>>> to > > > >>>>>>>>>>>>>> replace Processor but keep the class name in KIP-478. I > > > >>>>> wound up > > > >>>>>>>>>> creating a > > > >>>>>>>>>>>>>> new package for the new Processor. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Thanks, > > > >>>>>>>>>>>>>> John > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> On Wed, May 27, 2020, at 22:20, Yuriy Badalyantc wrote: > > > >>>>>>>>>>>>>>> Hi John, > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> I'm stick with the > > > >>> `org.apache.kafka.streams.scala.Serdes` > > > >>>>>>>> because > > > >>>>>>>>>> it's > > > >>>>>>>>>>>>>>> sort of conventional in the scala community. If you > > > >>> have a > > > >>>>>>>> typeclass > > > >>>>>>>>>>>>>> `Foo`, > > > >>>>>>>>>>>>>>> you probably will search `Foo` related stuff in the > > > >>> `Foo` > > > >>>>> or > > > >>>>>>>> maybe > > > >>>>>>>>>> `Foos` > > > >>>>>>>>>>>>>>> (plural). All other places are far less discoverable > > > >>> for > > > >>>>> the > > > >>>>>>>>>> developers. > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> I agree that the migration path is a bit complex for > > > >>> such > > > >>>>>>>> change. > > > >>>>>>>>>> But I > > > >>>>>>>>>>>>>>> think it's more important to provide good developer > > > >>>>> experience > > > >>>>>>>> than > > > >>>>>>>>>> to > > > >>>>>>>>>>>>>>> simplify migration. Also, I think it's debatable which > > > >>>>>>>> migration > > > >>>>>>>>>> path is > > > >>>>>>>>>>>>>>> better for library users. If we would create, for > > > >>> example, > > > >>>>>>>>>> `Serdes2`, > > > >>>>>>>>>>>>>>> library users will have to modify their code if they > > > >>> used > > > >>>>> any > > > >>>>>>>> part > > > >>>>>>>>>> of the > > > >>>>>>>>>>>>>>> old `Serde`. With my approach, most of the old code > > > >>> will > > > >>>>> still > > > >>>>>>>> work > > > >>>>>>>>>>>>>> without > > > >>>>>>>>>>>>>>> changes. Only explicit usage of implicits will need to > > > >>> be > > > >>>>> fixed > > > >>>>>>>>>> (because > > > >>>>>>>>>>>>>>> names will be changed, and old names will be > > > >>> deprecated). > > > >>>>>>>> Wildcard > > > >>>>>>>>>>>>>> imports > > > >>>>>>>>>>>>>>> will work without changes and will not lead to a name > > > >>>>> clash. > > > >>>>>>>>>> Moreover, > > > >>>>>>>>>>>>>> many > > > >>>>>>>>>>>>>>> users may not notice name clash problems. And with my > > > >>>>> migration > > > >>>>>>>>>> path, > > > >>>>>>>>>>>>>> they > > > >>>>>>>>>>>>>>> will not notice any changes at all. > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> - Yuriy > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> On Thu, May 28, 2020 at 7:48 AM John Roesler < > > > >>>>>>>> vvcep...@apache.org> > > > >>>>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Hi Yuriy, > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Thanks for the reply. I guess I've been out of the > > > >>> Scala > > > >>>>> game > > > >>>>>>>> for a > > > >>>>>>>>>>>>>>>> while; all this summoner business is totally new to > > > >>> me. > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> I think I followed the rationale you provided, but I > > > >>> still > > > >>>>>>>> don't > > > >>>>>>>>>> see > > > >>>>>>>>>>>>>>>> why you can't implement your whole plan in a new > > > >>> class. > > > >>>>> What > > > >>>>>>>>>>>>>>>> is special about the existing Serdes class? > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Thanks, > > > >>>>>>>>>>>>>>>> -John > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> On Tue, May 19, 2020, at 01:18, Yuriy Badalyantc > > > >>> wrote: > > > >>>>>>>>>>>>>>>>> Hi John, > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> Your suggestion looks interesting. I think it's > > > >>>>> technically > > > >>>>>>>>>> doable. > > > >>>>>>>>>>>>>> But > > > >>>>>>>>>>>>>>>> I'm > > > >>>>>>>>>>>>>>>>> not sure that this is the better solution. I will > > > >>> try to > > > >>>>>>>> explain. > > > >>>>>>>>>>>>>> From > > > >>>>>>>>>>>>>>>> the > > > >>>>>>>>>>>>>>>>> scala developers' perspective, `Serde` looks really > > > >>> like > > > >>>>> a > > > >>>>>>>>>> typeclass. > > > >>>>>>>>>>>>>>>>> Typical typeclass in pure scala will look like this: > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> trait Serde[A] { > > > >>>>>>>>>>>>>>>>> def serialize(data: A): Array[Byte] > > > >>>>>>>>>>>>>>>>> def deserialize(data: Array[Byte]): A > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> object Serde extends DefaultSerdes { > > > >>>>>>>>>>>>>>>>> // "summoner" function. With this I can write > > > >>>>> `Serde[A]` > > > >>>>>>>> and > > > >>>>>>>>>> this > > > >>>>>>>>>>>>>> serde > > > >>>>>>>>>>>>>>>>> will be implicitly summonned. > > > >>>>>>>>>>>>>>>>> def apply[A](implicit ev: Serde[A]): Serde[A] = ev > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> trait DefaultSerdes { > > > >>>>>>>>>>>>>>>>> // default instances here > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> Usage example (note, that there are no wildcards > > > >>> imports > > > >>>>>>>> here): > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> object Main extends App { > > > >>>>>>>>>>>>>>>>> import Serde // not wildcard import > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> // explicit summonning: > > > >>>>>>>>>>>>>>>>> val stringSerde = Serde[String] // using summoner > > > >>>>>>>>>>>>>>>>> stringSerde.serialize(???) > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> // implicit summonning > > > >>>>>>>>>>>>>>>>> def serialize[A: Serde](a: A) = { > > > >>>>>>>>>>>>>>>>> Serde[A].serialize(a) // summoner again > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> serialize("foo") > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> Examples are pretty silly, but I just want to show > > > >>> common > > > >>>>>>>>>> patterns of > > > >>>>>>>>>>>>>>>>> working with typeclasses in scala. All default > > > >>> instances > > > >>>>> in > > > >>>>>>>> the > > > >>>>>>>>>> usage > > > >>>>>>>>>>>>>>>>> examples are found using implicits searching > > > >>> mechanism. > > > >>>>> Scala > > > >>>>>>>>>>>>>> compiler > > > >>>>>>>>>>>>>>>>> searches implicits in a lot of places. Including > > > >>>>> companion > > > >>>>>>>>>> objects. > > > >>>>>>>>>>>>>> In my > > > >>>>>>>>>>>>>>>>> examples compiler will found `Serde[String]` > > > >>> instance in > > > >>>>> the > > > >>>>>>>>>>>>>> companion > > > >>>>>>>>>>>>>>>>> object of `Serde` typeclass. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> Also, I want to pay attention to the summoner > > > >>> function. > > > >>>>> It > > > >>>>>>>> makes > > > >>>>>>>>>>>>>> usage of > > > >>>>>>>>>>>>>>>>> typeclasses very neat and clear. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> The example above was the example of the perfect > > > >>> solution > > > >>>>>>>> for the > > > >>>>>>>>>>>>>> scala > > > >>>>>>>>>>>>>>>>> developers. But this solution requires to create > > > >>> separate > > > >>>>>>>> `Serde` > > > >>>>>>>>>>>>>>>>> typeclass, to make all this implicit searching stuff > > > >>>>> works. I > > > >>>>>>>>>> don't > > > >>>>>>>>>>>>>> think > > > >>>>>>>>>>>>>>>>> that it worth it, because a lot of code should be > > > >>>>>>>> reimplemented > > > >>>>>>>>>> using > > > >>>>>>>>>>>>>>>> this > > > >>>>>>>>>>>>>>>>> new typeclass. But the main point of my example is to > > > >>>>> show > > > >>>>>>>> the > > > >>>>>>>>>>>>>> perfect > > > >>>>>>>>>>>>>>>>> solution. And I think we should strive to provide > > > >>>>> developer > > > >>>>>>>>>>>>>> experience > > > >>>>>>>>>>>>>>>>> close to this. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> It's a bit out of the scope of my KIP, but I have a > > > >>> plan > > > >>>>> to > > > >>>>>>>> make > > > >>>>>>>>>>>>>>>>> `org.apache.kafka.streams.scala.Serdes` more closer > > > >>> to > > > >>>>> the > > > >>>>>>>>>> solution > > > >>>>>>>>>>>>>>>> above. > > > >>>>>>>>>>>>>>>>> It could be done in 2 steps: > > > >>>>>>>>>>>>>>>>> 1. Fix implicit names. > > > >>>>>>>>>>>>>>>>> 2. Add summoner function. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> And with this scala developers will be able to write > > > >>>>> almost > > > >>>>>>>> the > > > >>>>>>>>>> same > > > >>>>>>>>>>>>>> code > > > >>>>>>>>>>>>>>>>> as in the example above: > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> object Main extends App { > > > >>>>>>>>>>>>>>>>> import org.apache.kafka.streams.scala.Serdes // not > > > >>>>>>>> wildcard > > > >>>>>>>>>> import > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> val stringSerde = Serdes[String] > > > >>>>>>>>>>>>>>>>> stringSerde.serialize(???) > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> def serialize[A: Serde](a: A) = { > > > >>>>>>>>>>>>>>>>> Serdes[A].serialize(a) > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> serialize("foo") > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> Of course, wildcard import will still work. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> Other names will make this new entity (containing > > > >>> default > > > >>>>>>>>>> implicits) > > > >>>>>>>>>>>>>> less > > > >>>>>>>>>>>>>>>>> discoverable. And summoner usage, in this case, will > > > >>> look > > > >>>>>>>> weird: > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> object Main extends App { > > > >>>>>>>>>>>>>>>>> import > > > >>> org.apache.kafka.streams.scala.DefaultSerdes // > > > >>>>> not > > > >>>>>>>>>> wildcard > > > >>>>>>>>>>>>>>>> import > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> val stringSerde = DefaultSerdes[String] > > > >>>>>>>>>>>>>>>>> stringSerde.serialize(???) > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> def serialize[A: Serde](a: A) = { > > > >>>>>>>>>>>>>>>>> DefaultSerdes[A].serialize(a) > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> serialize("foo") > > > >>>>>>>>>>>>>>>>> } > > > >>>>>>>>>>>>>>>>> ``` > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> So, I think it's more important to provide a solid > > > >>> and > > > >>>>>>>> familiar > > > >>>>>>>>>>>>>> developer > > > >>>>>>>>>>>>>>>>> experience for the scala developer. And renaming (or > > > >>>>>>>> creating a > > > >>>>>>>>>> new > > > >>>>>>>>>>>>>>>>> version) of `Serdes` will not help here. > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> -Yuriy > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> On Tue, May 19, 2020 at 11:56 AM John Roesler < > > > >>>>>>>>>> vvcep...@apache.org> > > > >>>>>>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Hi Yuriy, > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Thanks so much for the KIP! I didn’t anticipate the > > > >>>>> problem > > > >>>>>>>> you > > > >>>>>>>>>>>>>> laid > > > >>>>>>>>>>>>>>>> out > > > >>>>>>>>>>>>>>>>>> in the KIP, but I find it very plausible. > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Thanks for pushing back on the “convention” and > > > >>> raising > > > >>>>> the > > > >>>>>>>>>> issue, > > > >>>>>>>>>>>>>> and > > > >>>>>>>>>>>>>>>>>> also volunteering a solution! > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> I’m wondering if we can “fix” it in one shot by just > > > >>>>>>>> deprecating > > > >>>>>>>>>>>>>> the > > > >>>>>>>>>>>>>>>> whole > > > >>>>>>>>>>>>>>>>>> Serdes class and replacing it with a new one > > > >>> containing > > > >>>>> the > > > >>>>>>>> defs > > > >>>>>>>>>>>>>> you > > > >>>>>>>>>>>>>>>>>> proposed. Then, people could just switch their > > > >>> import to > > > >>>>>>>> the new > > > >>>>>>>>>>>>>> one. > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Of course the new class needs to have a different > > > >>> name, > > > >>>>>>>> which is > > > >>>>>>>>>>>>>>>> always a > > > >>>>>>>>>>>>>>>>>> challenge in situations like this, so I might just > > > >>>>> throw out > > > >>>>>>>>>>>>>>>> ImplicitSerdes > > > >>>>>>>>>>>>>>>>>> as an option. > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Do you think this would work? > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Thanks again, > > > >>>>>>>>>>>>>>>>>> John > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> On Mon, May 18, 2020, at 23:35, Yuriy Badalyantc > > > >>> wrote: > > > >>>>>>>>>>>>>>>>>>> Hi, > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>> I would like to propose KIP-616 to fix naming > > > >>> clash in > > > >>>>> the > > > >>>>>>>> kafka > > > >>>>>>>>>>>>>>>>>>> streams scala API: > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>> > > > >>>>> > > > >>> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-616%3A+Rename+implicit+Serdes+instances+in+kafka-streams-scala > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>> Looking forward to your feedback. > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>> -Yuriy > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> Attachments: > > > >>>>>>>>>>> * signature.asc > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
