Many Diplomat generated Kotlin classes are unusable from Java

[mihnita]

All public APIs should be Java-friendly (should contain only Java types and should have valid Java names).

For example there is no way to use a org.unicode.icu4x.Locale class from Java.

companion object {
    @JvmStatic fun fromString(name: String): Result<Locale> { .​.​. }
    @JvmStatic fun normalize(s: String): Result<String> { .​.​. }
}
fun setLanguage(s: String): Result<Unit> { .​.​. }
fun setRegion(s: String): Result<Unit> { .​.​. }
fun setScript(s: String): Result<Unit> { .​.​. }

All of them return Result, which is a Kotlin class (https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-result/).

How to inspect what is available for Java:

• go to <repo_root>/ffi/mvn
• build (make then mvn compile)
• dump public methods and grep for - (javap target/classes/org/unicode/icu4x/Locale.class | grep ".*-.*")

Result:

public final java.lang.Object setLanguage-IoAF18A(java.lang.String);
public final java.lang.Object setRegion-IoAF18A(java.lang.String);
public final java.lang.Object setScript-IoAF18A(java.lang.String);
public static final java.lang.Object fromString-IoAF18A(java.lang.String);
public static final java.lang.Object normalize-IoAF18A(java.lang.String);

Since the methods return Object there is no way to call any Result methods (isFailure, getOrNull, getOrThrow, etc.)

---

Locale is just one example, but this happens in a lot of other classes.

[mihnita]

Good reference: https://kotlinlang.org/docs/java-to-kotlin-interop.html

[Manishearth]

Filed rust-diplomat/diplomat#1004. The primary goal of the Kotlin backend is to generate idiomatic kotlin, but we should also try and make it work for Java.

[mihnita]

generate idiomatic kotlin

I am not sure how idiomatic is the Result approach in Kotlin. It feels more like a Rust thing.

I was curious about it, and this is what I found about its history (entry from 2021):
https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103/3
"was introduced in 1.3 as an internal class first, as it was intended to be used by compiler generated code only - namely coroutines"
...
"Because of these two design issues, we do not encourage use of kotlin.Result as a return type"
but then
"Change of plans. We will allow returning kotliln.Result from functions"

Anyway, the problem is not really Result not being idiomatic Java. It is the fact that is @JvmInline and from Java it becomes Object, no ways to get the result. And that the function names are "mangled", so they can't be called from Java.
So not that is not Java friendly, it is unusable.

The methods are already annotated with @JvmStatic, which is intended to make methods more Java friendly.
I don't think it would be too hard to make this usable from Java.

[Manishearth]

Yeah, I'm not either.

I find this Reddit discussion to be illuminating, and it links to this popular blog post, which strongly advocates for using Result (and using exceptions for programmer errors).

So it seems like "Result is idiomatic" is the ideal that the Kotlin ecosystem wants, but the Result type as a practical matter doesn't work that well.

[jcrist1]

If, as part of rust-diplomat/diplomat#1004 , we introduce a config flag for result types throwing, then I think the long term goal of such a config should be complete java compatibility (The unsized types are supported IIRC). At least until there's more time to work on https://github.com/rust-diplomat/diplomat-java

[mihnita]

I've read all the comments on Reddit, and the blog.
They are good reads (although 4 years old, which might be a bit dated :-)

But I didn't get the feel that they advocate for Result.
There seems to be an agreement that something like Result would be nice, but Result as exposed by Kotlin is not good, and many people roll their own.

And with "roll your own" I would not consider the code "idiomatic"

we introduce a config flag for result types throwing, then I think the long term goal of such a config should be complete java compatibility

That might be an option...
Another (that I temporarily used for my experiments) was to add another throwing API that calls the one returns a Result.

@JvmStatic fun fromString(name: String): Result<Locale> { .​.​. }
@JvmStatic fun fromStringWithThrow(name: String): Locale { return fromString(name). getOrThrow() }

As a Java user I think I would prefer that to a flag.

[Manishearth]

As a Java user I think I would prefer that to a flag.

Note that when I say "a flag" I am saying a flag on Diplomat, i.e. a config you set during code generation time. Kotlin/Java users would only see one final state.

Please let us continue the discussion on rust-diplomat/diplomat#1004 where I have already listed these options in more detail, including foo vs fooThrows

[mihnita]

Note that when I say "a flag" I am saying a flag on Diplomat

Ah, got you!
Thanks, I'll continue on rust-diplomat/diplomat#1004 if I have something to add.