Hi Josep, Thanks for looking into this. As you said, it seems like there are a number of rough edges still. Do we have many users asking for this right now? If not, it may make sense to wait for things to get a bit more mature before adding the burden of a third Scala version. Ideally, we would drop Scala 2.12 before we add Scala 3 support.
Ismael On Fri, Oct 8, 2021 at 6:07 AM Josep Prat <josep.p...@aiven.io.invalid> wrote: > 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 >
