Hi Matthew, Comments below.
On Sat, Mar 18, 2023 at 2:27 PM Matthew Benedict de Detrich <matthew.dedetr...@aiven.io.invalid> wrote: > >1. The kafka module does not expose a public api (unlike kafka-clients or > streams-scala) and the usage of Scala (including the version) is an > implementation detail. > > This is irrelevant, the core problem is bringing in scala-library.jar and > potentially mixing in different binary incompatible versions. > I disagree. > > 2. The vast majority of kafka users do not use Scala and the Scala suffix > is a problem for them. For example, they may depend on kafka_2.12 and then > that stops working when support for Scala 2.12 goes away. > > I fail to see how this is a "problem". All of the common JVM build tools > already handle this transparently. You pick a Scala version, define it in > the build tool and then everything is handled for you. If you pick the > wrong Scala version then it will fail to resolve at which point you have > feedback thay you picked the wrong version. > If you have a Java project, you do not set a Scala version. Why would you? This suggestion would mean that if a user brings in Scala version X (from > some other dependency) that differs from Kafkas version they will get a > very hard to diagnose runtime error. > > > That's incorrect. kafka-clients is a pure Java library, does not include > the Scala suffix and does not depend on the kafka (aka core) jar. > > I am talking about clients of kafka such as streams which depend on core. > In fact if you look at the direct dependencies of kafka core (see > https://mvnrepository.com/artifact/org.apache.kafka/kafka/usages) you will > see there are a lot of libraries/runtimes which depends on kafka core. The streams module does not depend on the core module either, see: https://mvnrepository.com/artifact/org.apache.kafka/kafka-streams/3.4.0 Ismael
