Would you rewrite a small Kotlin library in Java just to avoid stdlib ?

[u/Decent-Decision-9028]

/r/Kotlin/comments/1w3f2fj/would_you_rewrite_a_small_kotlin_library_in_java/

[u/pgris]

In my java project I avoid kolin (and scala) libs, just to avoid dependencias with another stdlib. So I think you were right in doing so, keep the core in java.

BTW, Is it my imagination or back then when kotlin development started tha idea was to avoid having a stdlib at all, and reuse the java one?

[u/shponglespore → u/pgris]

I've never seen a language that had no std lib at all. Maybe C on an embedded platform?

I've seen a precedent for a very small std lib, like Rust crates built with no_std; they don't depend on the std crate, but they still depend on a much smaller crate called core. In Java terms it's like depending on java.lang without depending on the other java.* packages.

In the case of Kotlin, I would expect an absolutely minimal std lib to include types like kotlin.Any, which are presumed to exist by the language itself.

[u/slaymaker1907 → u/shponglespore]

Even on embedded, there are often system calls for things like random number generation. RNG is very important if you want to communicate on a shared channel. There are also all the macro headers.

[u/New_Enthusiasm9053 → u/slaymaker1907]

Depends on the type of embedded. An RTOS call isn't a system call in the classical sense since there's no real context switch.

[u/pgris → u/shponglespore]

I was not clear. My idea was that, at some point in history, Kotlin would not have had kotlin-stdlib, or classes like kotlin.collections.List, but use JDK classes only.

However I was looking for data to back my recollection, and it looks like I made everything up. Maybe was another language for JVM? Maybe my imagination only?

Anyway, it was nice to hallucinate, would I be able to replace an LLM soon?

That's an excellent question!

[u/vytah → u/shponglespore]

Isn't kotlin.Any just compiled to java.lang.Object on the JVM target?

Although there's one thing that peppers Kotlin binaries and currently comes from the Kotlin stdlib: calls to kotlin.jvm.internal.Intrinsics.checkNotNullParameter and friends.

[u/Decent-Decision-9028 → u/pgris]

Yeah, I feel confident now about my decision I think keeping the core Java was the right move

[u/Chipay → u/pgris]

BTW, Is it my imagination or back then when kotlin development started tha idea was to avoid having a stdlib at all, and reuse the java one?

You might be imagining things, the pitch was full interop with Kotlin from Java's call-site. Kotlin and Java share the same collections, arrays, signed types, etc.

If you do a size analysis of stdlib you'll find that most of it is collections, and most of that is extension functions adding collection-like methods to arrays. Although it does have its own types like unsigned primitives, sequences, ranges, etc.

[u/Joram2]

If it's an internal library that will be used by just you and coworkers, it may not matter.

If you want to make your library appeal to the broader public, then writing in pure Java without kotlin/scala support libs is important.

I'm actually facing a problem supporting a large enterprise project that uses three different third party libraries that use three different versions of the okhttp library which in turn uses three different versions of the kotlin stdlib, and this results in runtime clashes.

[u/Decent-Decision-9028 → u/Joram2]

It’s a small open source library I’m working on in my free time.

[u/aboothe726]

In my opinion, applications can be written in whatever JVM language they want, but libraries belong in Java, or at least a JVM language without any additional dependencies. Internal libraries tightly coupled to the underlying applications are more flexible, since that's generally more about packaging/DRY and is still just a consistent reflection of the same existing architecture choices, but anything with broader applicability should be Java.

[u/geodebug]

I think you got your answer but I’ll pile on that you should never write a library in anything but Java that you expect to be used with any number of JDK languages.

Too much bloat and unexpected incompatibilities. For example, if you’ve ever tried to use Spock (Groovy) for testing Kotlin code, you’ll soon learn that certain Kotlin structures won’t translate.

You’ll end up having to annotate your Kotlin code to make it more compatible.

[u/johnnybgooderer → u/geodebug]

It’s going to take annotations to write libraries in Java in a way that’s still ergonomic for kotlin applications that depend on it.

You have to choose a target and do your best to make it acceptable for other languages. Or just make it for your language and don’t even bother making it nice for the other ones until there is a demand.

[u/papers_]

If you intend for your library to be consumed by other JVM languages, then my opinion is that it should be written in Java first.

[u/morhp]

I would avoid Kotlin in the first place and I don't think just using core java is extra work. 

Kotlin has some nice features, but very often they lead to worse code than what you'd do in Java in the first place. I for example think checked exceptions are pretty important to help you define a proper exception control flow in some cases (although I can see they're annoying with lambdas). Or the .? operator sometimes makes you go towards nullable values when some other design that avoids null completely might make handling of errors or missing data more clear.

Also Java in general is much better documented than Kotlin.

Also I think a lot of the Kotlin design choices like companion classes are relatively bad, I much prefer what the Java guys are prototyping at the moment with type classes/witness classes. Or records make more sense to me than Kotlin data classes. Data classes seem worse compatibility wise and they give you a lot of extra methods that you might not need or want.

[u/johnnybgooderer → u/morhp]

Java really needs nullable and non nullable types. Nullaway just isn’t able to enforce a variety of common usecase. That’s what makes me reach for kotlin 99% of the time.

[u/pjmlp → u/johnnybgooderer]

I am programming since 1986, had a big focus on FP and LP languages during university, nullable types isn't that take or break feature in daily work.

Even less so, if the AI overlords are the ones doing the actual programming.

[u/johnnybgooderer → u/pjmlp]

It’s a very very helpful feature that saves time and headaches. It lets you express more with less.

[u/hadrabap]

I would never write it in Kotlin in the first place 🤣

Minimize dependencies as much as possible. When projects grow, they tend to manifest classpath hell.

[u/Decent-Decision-9028 → u/hadrabap]

Also, another point someone brought up was worrying about kotlin specific constructs leaking into the java facing api

[u/hadrabap → u/Decent-Decision-9028]

Yep. I see it a lot. The contracts (API + model) written in fancy Kotlin (lots of Kotlin features) doesn't look native Java and makes things uglier than necessary 😀 I still recommend writing contracts using plain interfaces, actual Java Beans plus java.base as dependency (maybe Jakarta EE contracts, if it's intended for enterprise application). That's about it. Everything extra creates problems down the line in the life-cycle than good.

I really should kick myself in the butt and finalize the material/book I'm working on.

[u/javaprof]

It's incorrect to compare Kotlin stdlib to Scala stdlib or even Guava. Kotlin stdlib much-much smaller and do not break ABI every release. So given that it's absolutely fine for me to use library that brings kotlin stdlib, especially because there are already a lot of libraries like that. What an library never ever should bring - is Guava

[u/kevinb9n → u/javaprof]

Yeah, I agree with that.

[u/Critical_Top3117]

OpenAI Java sdk is written in Kotlin

[u/johnnybgooderer → u/Critical_Top3117]

OpenAI reimplemented the Java sdk in kotlin?

[u/_INTER_ → u/Critical_Top3117]

Something to never use then.

[u/pjmlp]

I avoid Kotlin in general, outside Android.

[u/_INTER_]

If I need to step debug deep enough into a (core) library AND the decompiler produces only garbled mess identifying it as another JVM language source, the library is janked out and replaced. Otherwise I don't care. Happens rarely enough, but did happen.

[u/bh-m87]

Kotlin > java

[u/koflerdavid]

It's not Kotlin and probably off-topic on that thread over there, but Kotlin should try to break up that standard library so people don't have to eat all of it when they want to use a Kotlin library.

[u/woj-tek]

While kotlin lib is a must if you intend for your library to be consumed in Kotlin (and Kotlin native so not only Android and Desktop) if you are mostly targeting JVM echosystem I'm not sure Kotlin is all that benefitial here… (especially with faster Java delivery rate…)

[u/revilo-1988]

Ne warum sollte ich das tun