KAFKA-12357: Do not inline methods from the scala package by default#10174
KAFKA-12357: Do not inline methods from the scala package by default#10174ijuma merged 1 commit intoapache:trunkfrom
Conversation
As mentioned in apache#9548, users currently use the kafka jar (`core` module) for integration testing and the current inlining behavior causes problems when the user's classpath contains a different Scala version than the one that was used for compilation. An example error: `java.lang.NoClassDefFoundError: scala/math/Ordering$$anon$7` We disable inlining of the `scala` package by default, but make it easy to enable it for those who so desire (a good option if you can ensure the scala library version matches the one used for compilation). While at it, we make it possible to disable scala compiler optimizations (`none`) or to use only method local optimizations (`method`). This can be useful if optimizing for compilation time during development. Verified behavior by running gradlew with `--debug` and checking the output after `[zinc] The Scala compiler is invoked with:`
|
@chia7712 I was thinking to include this in 2.8 since it's low risk and it fixes a regression when it comes to writing integration tests with Kafka. |
chia7712
left a comment
There was a problem hiding this comment.
overall +1.
one question:
As we don't guarantee to keep core compatibility, is it worthwhile to exclude scala inlining by default?
|
@chia7712 For better or worse, libraries like https://github.com/embeddedkafka/embedded-kafka are often used. And there isn't a great alternative. Getting an exception when there's a mismatch in the patch version of scala-library is pretty surprising. It seems better to aim for ease of use until there's a better way of handling this. Do you agree? |
make sense. be a friendly libraries :) |
|
Merged to trunk and 2.8 branches. |
…10174) As mentioned in #9548, users currently use the kafka jar (`core` module) for integration testing and the current inlining behavior causes problems when the user's classpath contains a different Scala version than the one that was used for compilation (e.g. 2.13.4 versus 2.13.3). An example error: `java.lang.NoClassDefFoundError: scala/math/Ordering$$anon$7` We now disable inlining of the `scala` package by default, but make it easy to enable it for those who so desire (a good option if you can ensure the scala library version matches the one used for compilation). While at it, we make it possible to disable scala compiler optimizations (`none`) or to use only method local optimizations (`method`). This can be useful if optimizing for compilation time during development. Verified behavior by running gradlew with `--debug` and checking the output after `[zinc] The Scala compiler is invoked with:` Reviewers: Chia-Ping Tsai <chia7712@gmail.com>
As mentioned in #9548, users currently use the kafka jar (
coremodule)for integration testing and the current inlining behavior causes
problems when the user's classpath contains a different Scala version
than the one that was used for compilation (e.g. 2.13.4 versus 2.13.3).
An example error:
java.lang.NoClassDefFoundError: scala/math/Ordering$$anon$7We now disable inlining of the
scalapackage by default, but make iteasy to enable it for those who so desire (a good option if you can
ensure the scala library version matches the one used for compilation).
While at it, we make it possible to disable scala compiler optimizations
(
none) or to use only method local optimizations (method). This canbe useful if optimizing for compilation time during development.
Verified behavior by running gradlew with
--debugand checking theoutput after
[zinc] The Scala compiler is invoked with:Committer Checklist (excluded from commit message)