Pure Kotlin?

[mccartney]

Context: I am new to Kotlin and somewhat new to Android development.
I read the comment which breaks down the work towards IOS app.

I am trying to learn and possibly contribute.

Question:
Can someone confirm that since the goal is to use Kotlin Multiplatform Mobile we need to:

1. get rid of direct usages of any Java standard library - even basic things like java.io, java.util, java.net, etc,
2. and get rid of any libraries built with the same,
3. and have all the code in pure Kotlin?

If so, taking an example do we need to replace all usages of java.net.URLEncoder with something like https://github.com/ethauvin/urlencoder?
Or https://kotest.io/ instead of assertj (not sure if it's worth for just a few uses)?

[westnordost]

Nice, good to hear! Yes, to all three.

Though, "Kotlin multiplatform" libraries usually consist of platform-specific code, too. For example, a library that parses some XML document and does some things with it, could maybe use LibXML2 for native, Jackson XML for JVM and DOMParser on JS.... or whatever. So, a Kotlin multiplatform library doesn't have to be pure Kotlin, it can use different dependencies for different platforms.

For e.g. URLEncoder: Yes, would need to be replaced. Replacing Java dependencies in UI code is however for the time being of lower priority, because the whole UI is currently Android, thus JVM dependent.
I want to be cautious however when introducing new dependencies, they should be established so there is a certain guarantee that there are not any bugs and that it will be maintained in the future. So, "official" Kotlin libraries are usually the best. KTOR is featured by JetBrains and hence I expect that its components are reasonably well maintained. So whatever KTOR uses for URL encoding (it must have this, no?) is probably fine.

We are using assertJ? ... you are right, but only at very few places and mostly only for containsExactlyInAnyOrder. Could have instead a simple helper function that does the same. The bigger JVM-specific chunk in the tests is Mockito. There are various possible replacements, such as MockingBird, Mockative or MockMP. Didn't have a closer look at those yet, though.

Also, note that anything in buildSrc can be Java. These are just the build scripts.

Also, anything Android-specific naturally also can have Java dependencies.

[mccartney]

Could have instead a simple helper function that does the same

Trying it out at:
#5349

[mccartney]

Thanks for taking the time to answer. I appreciate it.

So, to summarize again. At a high-level we need to get rid of all Java. Specifically I understand:

• the code in de.westnordost.streetcomplete.screens and alikes is not the priority right now, it will need to likely be dually-implemented or some other solution which would cater for IOS UI dev framework
• replacing key 3rd party dependencies with some KMM-enabled ones takes extra care - first the usual one (project status, maintainence level), but also their support for IOS platform
• for non-key dependencies it's likely the best to avoid them at all, rather than finding a replacing KMM-enabled library
• Gradle stays

[westnordost]

Kotlin Multiplatform projects still have gradle as their build system.

Anything view related has no priority right now, because the plan would be to migrate the UI eventually to Compose Multiplatform. The current view dependencies are mostly Android-specific anyway. On the other hand, logic that is close to but not UI logic per se, for example date formatting, is something worth looking into already, because regardless of the UI framework used, date formatting needs to be done on all platforms.

That said, getting rid of JAva in tests has also less priority because it's fine to still run the tests for the common kotlin code on the JVM. It would be still nice though. Including getting rid of the Android-specific tests. (Most of these tests test the DAOs that handle the database, they are in androidTests only because an SQLite database is already included in Android with no extra dependencies, so it was easier to just dump those into that folder.)

Regarding avoiding dependencies: This is not really a requirement of migrating to a pure Kotlin codebase + dependencies but rather a personal preference of mine, I guess. I like to avoid having too many dependencies, or at least, there's always the consideration whether a particular dependency is really worth it. Especially the "Kotlin multiplatform" ecosystem is rather small and new so far, so I expect these dependencies to be on average less stable and less proven/guaranteed to be maintained. I am happy for example that @neonowy implemented the in-app logging without introducing any (Kotlin multiplatform) dependencies like Napier, Kermit, Klogger, KmLogging etc. pp. because we don't actually need any fancy logging functionality which these libraries may or may not offer. And I am happy that you created a PR with removing AssertJ dependency and basically just replacing it with one helper function in the tests :-)