Heyo! I've got a KMP project an am using value classes, but cannot for the life of me figure out how to require their use in Java from an interface method.

sealed interface Key {
    fun descriptor(address: Address): String
}

@JvmInline
value class Address(@JvmField val value: String)

Calling From Java:

public class SomeClass {
    public void someFunction(Key key) {
        // Key.descriptor accepts a String, not an Address
        String descriptor = key.descriptor("");

        Address address = new Address("someaddress");

        // key.descriptor does not accept an Address and IDE shows error
        String descriptor2 = key.descriptor(address);
    }
}

Any Ideas?

Hello, probably this is what you are looking for https://kotlinlang.org/docs/inline-classes.html#calling-from-java-code

In Java, you would call

SomeClass().someFunction("someaddress")

-- value types are not enforced by the JVM

With some ingenuity, I was able to remove value classes from my public APIs using sealed interfaces and operator function

sealed interface Port {
    val value: Int

    companion object {
        @JvmStatic
        @Throws(IllegalArgumentException::class)
        operator fun invoke(port: Int): Port {
            return RealPort(port)
        }
    }
}

@JvmInline
private value class RealPort(override val value: Int): Port {
    init {
        require(value in 0..65535) {
            "Invalid port range"
        }
    }
}

And calling from Java:

Port port = Port.invoke(65536); // Will throw IllegalArgumentException

This way, all my interfaces that take a

Port

now compile to the sealed interface, instead of the primitive type.

@Matt Nelson interesting approach. Worth noting that this has two hits against it, in addition to the obvious positives: 1) far less efficient 2) difficult to read

Yeah, I'm still playing with things to get it right. Performance wise, data classes are very bad. See my test results HERE

What application are you writing that is using so many port numbers you have to worry about inefficiency?

It's a wrapper for Tor

You know, that's just about the one valid answer you could have given to that question right?

lol, yes.

I still think it'd be fully wrapped on the java side, and maybe on the kotlin side too. It might lose the perceived benefit. You should check out the bytecode.

Decompiled byte code shows it's boxed.

What are your memory constraints? Caching every instance is only 0.5 MB

As minimal as possible, as running Tor on Android is a hog.

It does bear asking the question -- why not just use ints straight up? Maybe create a

typealias

if you're feeling curious.

For sure, but Tor is very picky about the strings that it receives via it's control port. Using value classes is a very low cost way to offload knowledge library consumers have to have when interacting with the APIs (how many people know that a v3 onion address is a 56 character base32 encoded lowercase string?) by handling all of that and returning a wrapper, it can be passed around everywhere straight from the controller response all the way down to the DB. Very low friction on library consumer side as the APIs "guide" things before even making it to the request being sent to the controller, so.

@Matt Nelson my friend, I am forever grateful to you. I have used this to create a

WrappedLong

implementation that is compatible with JS but performs very quickly on JVM. You are a genius.

Created a library for this specific issue of Kotlin

value class

not compiling to platform code. https://github.com/05nelsonm/component-value-clazz