Kotlin for .NET

There have been a few discussions on this, notably here:

mainly discussing whether or not there is a requirement for Kotlin on .NET.

I’m more interested in a different angle: is it feasible?

In Saxon we have a product written in Java that is increasingly moving onto other platforms (.NET, JS, native) using a variety of technologies, and involving more code forking than we would like. If we could migrate our code to Kotlin and target all those four platforms it would be an enormous step forward. We’re not interested here in whether Kotlin can complete against other .NET-only languages; its unique-selling-point would be multi-platform targeting, and there’s really nothing else that can do that. We’re having to rethink our .NET strategy because of the demise of IKVM, and because IKVM never did and never will support .NET Core.

If we offered to fund the development, with the aim of releasing something as open source, would we find someone interested in doing it? If you think it can be done and you think it’s an interesting project, then let us know and we can talk about it.

I think that in theory it is quite possible. CLR byte code is not so different from JVM and as far as I remember, memory model is also similar. But the main question is how much will it cost. You need to create a new compiler for it. Probably it would be easier to invest in general replacement of IKVM. It would both allow to run kotlin on .NET via bytecode translation and run plain old java programs as well.

I would imagine there’s a lot of information available if you work from source that’s lost if you work from bytecode, so a code-generator backend for CLR could do a better job that generating Java bytecode and then converting. In particular, you could re-target a lot of the commonly-used APIs (such as collection classes and I/O classes) onto .NET equivalents.

You have a point, but still it is a question of price. It would be the same for both cases, but there are much more people, wanting to invest in general JVM to CLR transformer than people wanting only kotlin.

You do not need direct CLR code generation to retarget API. If you have a way to reference those API from platform-declaration (kotlin IR wrappers or whatever), then it does not matter, how actual byte-code transformation goes. Of course, CLR has some features that JVM does not (like reified generics).


I have experience in compilers, code converters and IL bytecode and find such effort interesting. I also believe Kotlin is superior to other languages including C# with Rider in terms of productivity, but also that the .NET platform is far better than the JVM one (bytecode, API design, and optimization), specially while project Valhalla is taking that long.

Some OSS projects covering these areas I created in the past:

1 Like

Looks interesting! Drop us a note - mike at saxonica.com - and we’ll discuss.

Isn’t there a problem with the license for java standard library or something which you can’t avoid when you have any jvm bytecode you want to transform? I thought that was one of the reasons why k/n doesn’t support jvm-libs. Why would this be different with a JVM to CLR transformer?

What do you think you would need to do that isn’t allowed by the Java or OpenJDK licenses?

After looking into it again I can’t really find anything. Maybe I just imagined it. I mean there was this big lawsuit between Google and Oracle, but that went in favor of creating custom versions of the jvm. And I thought that JetBrains decided to not create a jvm transpiler for some legal reason, but I can’t find anything about it anywhere. So I guess just ignore my earlier comment :wink:

1 Like

As far as I can tell, Kotlin common runtime could be implemented easily with .NET API (kotlin package), and then you can just use .NET APIs from Kotlin, no Oracle’s API or Bytecode involved at all in that process.


If Kotlin can do to C# what it did for Java that would be amazing. It would make using Unity3D so much nicer. Plus you could easily port your game logic to run server side on the JVM.

The biggest issues I see from a users perspective would be surfacing and interfacing with C# struts.

1 Like