[
https://issues.apache.org/jira/browse/KAFKA-14524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17654356#comment-17654356
]
Josep Prat commented on KAFKA-14524:
------------------------------------
Hi [~ijuma],
I'm 100% agreeing with splitting `core` into multiple modules. However, I think
the risk of a rewrite from Scala to Java is quite high. Rewriting core from one
language to the other is opening the door to new bugs, performance regressions,
and even in some cases, we might stumble upon some previous unexpected
behaviors that the rest of the codebase relies on. I know that Scala does use
some tricks at bytecode level sometimes resulting in bytecode that is not
reproducible when writing Java.
Regarding Java -> Scala interoperability, this has been a big problem in Scala
versions prior to 2.12. Since 2.12 the situation improved substantially and
using Scala code from Java is now friendlier.
So in summary, I agree with splitting `core` into multiple modules, but I fail
to see the benefits of a rewrite of the `core` module from Scala to Java.
> Modularize `core` monolith
> --------------------------
>
> Key: KAFKA-14524
> URL: https://issues.apache.org/jira/browse/KAFKA-14524
> Project: Kafka
> Issue Type: Improvement
> Reporter: Ismael Juma
> Priority: Major
>
> The `core` module has grown too large and it's time to split it into multiple
> modules. A much slimmer `core` module will remain in the end.
> Evidence of `core` growing too large is that it takes 1m10s to compile the
> main code and tests and it takes hours to run all the tests sequentially.
> As part of this effort, we should rewrite the Scala code in Java to reduce
> developer friction, reduce compilation time and simplify deployment (i.e. we
> can remove the scala version suffix from the module name). Scala may have a
> number of advantages over Java 8 (minimum version we support now) and Java 11
> (minimum version we will support in Kafka 4.0), but a mixture of Scala and
> Java (as we have now) is more complex than just Java.
> Another benefit is that code dependencies will be strictly enforced, which
> will hopefully help ensure better abstractions.
> This pattern was started with the `tools` (but not completed), `metadata` and
> `raft` modules and we have (when this ticket was filed) a couple more in
> progress: `group-coordinator` and `storage`.
> This is an umbrella ticket and it will link to each ticket related to this
> goal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
