Hi there, For the last month I was actively working on migrating Apache Kafka to Scala 3. For what I could see, Apache Kafka is the biggest mixed Java-Scala project to attempt a migration to Scala 3. This means, a lot of regressions in regards to Java and Scala interoperability at bytecode were found within this task. You can take a look at the PR here: https://github.com/apache/kafka/pull/11350 Currently, the status of the migration is as follows:
- All tests pass in Scala 3 except one ( KafkaApis#getAllTopicMetadataShouldNotCreateTopicOrReturnUnknownTopicPartition). Root cause for this is this bug with no easy workaround: Type erased for by-name parameters lampepfl/dotty#13638 <https://github.com/lampepfl/dotty/issues/13638> - All tests pass in Scala 2 - It still uses a snapshot build of Gradle with support for Scala 3 - Spotbugs detected some new errors when the code was compiled with Scala 3. Some are simply false positives, but a small subset seem like they might be legit bugs in Scala 3. I still need to come up with a minimized reproducer for those cases. As one can see, most of the changes are arguably low-level and no big rewrite was needed. The biggest refactoring was splitting several classes into their own file. Changes made in this PR could be categorized in 3 different groups: a) Needed changes because of changes in syntax or compiler being currently more strict b) Changes where a workaround is present but they are (or will be) fixed in upcoming Scala versions c) Changes in the build file In order to have a smooth and manageable migration to Scala 3, I propose perform the migration in several steps: - Firstly apply all changes that would fall into category *a)* - Once a new Scala version that incorporates the mentioned fixes is released, revisit point changes in point *b)* - Once Type erased for by-name parameters lampepfl/dotty#13638 <https://github.com/lampepfl/dotty/issues/13638> is resolved or a workaround is found and Gradle with Scala 3 support is released we could tackle the final step and incorporate changes mentioned in point *c)* - After this, we would run the Scala Migration Tool to automatically rewrite the code that uses removed syntax or language constructs. (See https://docs.scala-lang.org/scala3/guides/migration/tooling-migration-mode.html ) What do you think about this approach? Please feel free to share your opinion on the proposed plan. Also, I'm not sure if this should be written in a KIP form or not, no public interfaces needed to be modified. For extra information, these are the bugs reported to Scala 3 so far: - https://github.com/lampepfl/dotty/issues/13549 - https://github.com/lampepfl/dotty/issues/13572 - https://github.com/lampepfl/dotty/issues/13630 - https://github.com/lampepfl/dotty/issues/13638 - https://github.com/lampepfl/dotty/issues/13645 Thank you in advance! -- Josep Prat *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491715557497 *w:* aiven.io *e:* josep.p...@aiven.io
