Why Scala?

[aweck]

Maybe a stupid question and feel free to close. But is there any interest in a kotlin re-write with a more modern UI? It would open up the floor for a whole lot more Android devs (including myself) to contribute.

Would be happy to help with this if desired. Thanks!

[ge0rg]

Haha, yeah. Why Scala!

I've written about the reasons in a blog post from 2011, a loooong time before Kotlin was a thing for Android development.

It used to be more-or-less-working back then, and the trade-offs were acceptable. Now, it looks like gradle-android-scala-plugin is abandonware and I'm its only user, and the compile takes 3 minutes and longer. And there are no incremental compiles. And everything is baaaad.

This has been really frustrating and the opposite of a sane development environment, and so yes, I'm actively looking to move the project to Kotlin.

However, I don't want to start from scratch, but instead incrementally move the code base, and thus it will remain baaaaad for a while before it will become better.

[penguin359]

I've just recently migrated a couple of Android apps of mine from Java to Kotlin and was surprised to see how well mixed Java/Kotlin worked. I did not need to migrate all at once. However, I have not used Scala at all. Being a JVM-based language, I would assume it has a similar level of compatibility. Android Studio includes a nice Java to Kotlin to quickly move in bulk before improving it to be more idiomatic Kotlin. Not sure about Scala. Either way, I'm happy to work in whatever the native project language is. As long as there's enough existing code for an example, it's usually not to hard to work in a new language.

[ge0rg]

it's usually not to hard to work in a new language.

That's a nice attitude that's not shared by many developers. It would be awesome to have a build system that can do incremental builds in significantly less than a minute, but it looks like both the gradle-android-scala projects and the sbt-android projects are abandonware and I should be lucky that they work at all. If you manage to find the right incantation to make either one of them create debug APKs in a fraction of the current build times, then there is probably no need to go away from Scala.

[penguin359]

I'm not sure if you've had a chance to look at the language, but it's very obvious that Kotlin was heavily influence by Scala. In fact, the author states that he looked at Scala as the closest language to his desired goals, but it was just too slow to compile so he create Kotlin, another JVM compatible language that looks like Scala, but compiles at the speed of Java. I expect this will be both a help and a hindrance to working in Scala especially as I go back and forth between my other Android project AMSAT Status written in Kotlin.

[penguin359]

Back on the topic of the Gradle plugins for Scala on Android, I've gotten a little frustrated with the build times so I've spent this weekend dissecting AllBus's fork and trying to update it to work with a newer version of the Android build plugin and Zinc to see if I can get some improvements there. I've made some progress and worked through several compatibility issues, but I am now getting errors during the compile command do to a ClassNotFoundException on scala.util.PropertiesTrait$class. I am hoping to be able to work through it with the debugger and get it working, but it is nested so deeply with Java reflection APIs that it's difficult to see the whole picture. I've also looked at porting the Gradle Scala plug-in over as a replacement. It currently can't be used as-is since it depends on the Java plug-in which conflicts with the Android plug-in, but I might be able to swap that out in a fork.

I'd be curious for any insights you might have on these plug-ins.

[ge0rg]

I agree with you that Kotlin looks like a nice clean and fresh JVM language, and I'd immediately use it for any new Android project (even if just to see how well it actually works under the hood)!

OTOH, I currently don't have the time to invest into the rewrite of APRSdroid in Kotlin, and this task probably requires significant history knowledge of the kludges that the app contains, so I'm rather sceptical about "outsourcing" it, even to a very determined volunteer like you. My hope is that my situation will resolve some time next year, and I'll be able to start improving and migrating the code base then. Test case coverage could increase my confidence in doing quick&dirty ad-hoc single-class-migrations ahead to that, and also in accepting PRs, but I've not really made my mind about the best strategy to get out of the mess.

That said, I've always struggled to understand how the gradle plugins work internally, short of grepping the error codes I see in the source code (and often turning up without results).

I've tested the following forks so far:

• AllBus, release 3.5.1 (as it matches my tooling version and works, albeit very slowly; also tries to compile VIM's .swp files and chokes on them; also creates an installable but incomplete APK roughly every second time)
• AllBus 3.6.2-M2 (didn't work, had some obscure error messages and I gave up after a hour of grepping and googling)
• Wire's fork (v1.6, IIRC it worked some time in 2019 or 2020 but didn't solve any of the problems and was more outdated than Allbus)
• a long time ago I was using the original(?) jp.leafytree.gradle and the com.github.xingda920813 forks, but that was with matching old gradle versions and Android Studio made me upgrade.
• Scala's SBT with Android plugins (I've tried to create some initial project config, but it never even produced something remotely looking like an APK)