Kotlin-native: JRE support for Kotlin native (like J2Objc)

[sarsonj]

Kotlin Native is great, but the big problem for now are libs. Like networking. Like JSON / XML parsing. Like tons of other things. Libs, that could be used on both iOS / Android.

We are currently using J2Objc in same way, how Kotlin native works (as was introduced in Kotlin native 0.5 - calling Kotlin from Swift). Guys on Android are using Kotlin for frontend and guys on iOS develop in Swift. The common code is written in Java and used natively on Android / through j2Objc on iOS. We love to move to Kotlin because it is much better language, similar to Swift. Also no need to use 3 languages on one project, right? But huge advantage on J2Objc is JRE implementation (JRE emulation project) - so that is is possible to use GSON parser, guava, networking, local database (through Squidb) or any other Java library, that was developer during latest 20+ years.

If we want to go Kotlin way, we will have nothing to base on (expect great language, that is fine, but not enough). So what about to support JRE in Kotlin native, same way, how J2Objc is do? Maybe reuse JREEmulationProject from J2Objc? I think that it will rocket Kotlin Native adoption significantly!

[olonho]

Kotlin/Native provides access to whole native infrastructure, where JSON parsers, networking, databases etc. are available as well. So writing bridge to JRE doesn't look absolutely needed.

[sarsonj]

@olonho you are right, but problem is, that this native infrastructure is not multiplatform. It means, you need to use different implementation of networking on Android (Java based) and different on iOS (C/Swift based). Save with other things - even basic things like parsing JSON, security libs etc. With j2objc you don't need to do this - you just use java based SquiDb and you have local databse solved. You can use Java networking on both iOS and Android - networking solved. You can use GSON on both platforms.

The problem is even bigger, because native API for such things has different approach on each platform, so that unity them into some Kotlin wrapper is not painless thing.

[olonho]

For that, multiplatform libraries with different implementations on different platforms may help.

[sarsonj]

@olonho right, and that is the problem - they doesn't exist. The biggest problem is, that on Android developers don't use Kotlin native, but Kotlin JRE (it is also used in Calculator example in Kotlin native samples folder). On iOS Kotlin Native is used. I don't know much (if any) libraries, that are multiplatform and supports both JRE and C.

[olonho]

Wide range of APIs is available out of the box with platform APIs.

[kpgalligan]

@sarsonj Multiplatform libraries will need to be created to use Kotlin Native and Kotlin JRE and share code. That work is starting up in various parts of the Kotlin open source world. We've done extensive J2objc library work, and will probably create a multiplatform db primitive library soon(ish), but then somebody will need to create multiplatform Kotlin db libraries. A "native JRE" doesn't seem to be in the cards. However, you can call your J2objc code from Kotlin native. This is old, but should still work: https://medium.com/@kpgalligan/droidcon-nyc-on-ios-with-kotlin-native-5a6a2749057e.

[olonho]

As we do not have plans for fixing that for now, I an closing it. Maybe reopen once reprioritized.

[omainegra]

I believe some parts of the JDK should be compiled and available to kotlin-native, like guys from scala-native are doing in here. It's really hard to reuse code between Android and iOS when you can't event call java.util.Locale

[kpgalligan]

I'll chime in here. I ported quite a bit of stuff to J2objc over the past couple years (more info).

Looking at that scala list, some of that would be helpful, but also a lot of that is effectively in the common stdlib, and I would expect equivalent libraries from Jetbrains to continue being released as time goes on, but they won't be direct Java ports. I would speculate because Kotlin on other platforms isn't just "bringing JVM to llvm" as much as making a language that can make sense on all of these platforms.

For the immediate future there is a lack of libraries, but this is quickly being rectified. For an example of using sqlite, sqldelight, and shared prefs in an app, see this.

I experimented for a while using J2objc as an underlying implementation for the JVM on K/N, and while you can make it work, ultimately I think the long view here is a cleaner implementation. See video on my thoughts there, if interested. Kotlin multiplatform libs will start appearing for everything pretty soon, especially after multithreaded coroutines become viable. I'd aim for 4th quarter or early 2019, unless you're very familiar with Kotlin/Native.