Would it make sense to translate what's missing of the Java standard library in Kotlin common code?

EDIT: The repo is up :slight_smile: if you have any port of a missing class in common code don’t hesitate to pull request! Any help is very much appreciated.

First question of all, would it be legal? And then, would it make sense?
My first thought goes to java.util (damn I want those tree maps so bad).
Would a community powered repository make sense?

1 Like

I think in would be good idea to try. As far as I can understand, Kotlin team is currently stretched very thin, so any help would be good. So if you start the repository, I think the community could help. And later some parts of it could be merged in stdlib or distributed as stdlib-extras.

Well, here it is, I’ve sent you the collaboration invite. The problem now it what codestyle to use? I don’t think that translating 1-to-1 Java into Kotlin common would be possible or make sense.

First of all, I do not like the name. It interferes with kotlin common modules. Maybe kotlin-extras?

As for content, we should start with things we need. No reason to port everything. I think that some kind of voting process is in order, like implement the feature if it has more than some number of votes. Would you write a list of features that you really miss in everyday multiplatform kotlin?

GNU license?
It never will be included in official stdlib.

1 Like

I do not understand difference between open source licences. Would you propose better license?

Kotlin stdlib is under Apache 2.0, so better use it too.

I use Apache 2.0 everywhere, but I do not really understand the difference. Could you explain?

I’m not lawyer, and do not really understand too… :slight_smile:
But GPL definitely differs from Apache/MIT/etc, and if it intended to eventually be included to stdlib - it should not be under GPL/LGPL.

May I ask why?

You can transpile Java to JavaScript or compile bytecode to native code. Kotlin can call Java. Is there any particular reason for doing such work beyond a vague feeling that it’s better if everything is in Kotlin?

I agree, it was the first thing that popped in my mind.

May work, more ideas?

Totally agree. I can write my owns but I cannot speak for everybody. Is there a service you recommend (something like Lithium Ideas, it is costly tho)?

Well I do not as well but since the Kotlin stdlib is Apache 2.0 I’d go for the Apache one as well.

Say a company have to build their library for iOS and Android. If you have a comprehensive stdlib for the common module you could do that in a snap! Write once, test once, compile once, release once, ecc…
The are many more use cases where other languages just could not do the same job in a such easy way.

Kotlin aims to create a number of multi-platform libraries to simplify further multi-platform development. Things like a TreeMap in fact do not require any platform-specific tricks, but are used quite frequently. I am not saying kotlin community should blindly duplicate everything there is in Java, but some things are worth having without to spell them explicitly when writing JS application.

And no, you can not directly compile bytecode to native code, at least (you can do it with Graal) the result will be quite different from the one produced by kotlin-native.

1 Like

Maybe start with repository issues?

Maybe kotlin-multiplatform-stdlib-extras ?

stdlib is multiplatform by default. I think it is OK, but it has some claim for being official stdlib addition which is not correct.

Official would be something like kotlinx-stdlib-extras :slight_smile:

And point is - on JVM and Android it would be just bunch of actual typealias ..., but on ios, posix etc - have non-trivial implementation.

Do you have example of what do you want? We started with the treemap. I am not sure JS has them out of the box.

Well, just open for example avian/TreeMap.java at master · ReadyTalk/avian · GitHub , press ctrl-shift-alt-k and fix conversion errors.
Repeat.

Is there any call for immutable variants of the TreeMap and other data types?

It depends on what do you mean by “immutable”. Real immutable collections live here. But what we usually mean by immutable are actually read-only.

By the way, good idea. If we will implement something form scratch, we’d better make separate implementations for writable and read-only ones.