Why do I have some "*-GBYM_sE*" suffixes added to some of my methods in the .jar file generated for ...

# multiplatform

[Sylvain Patenaude]

Why do I have some "*-GBYM_sE*" suffixes added to some of my methods in the .jar file generated for target "jvm"? When I try to call my Kotlin MP library from Java, I see the suffix-added names. 🤔

[diesieben07]

Kotlin adds suffixes for internal methods and also methods that take an inline-class as a parameter. Is either one the case for you?

[Sylvain Patenaude]

Indeed, it seems at first glance that the affected functions have a parameter UByteArray. These insigned types are implemented as inline classes if I remember correctly.

Is there a workaround for this?

[diesieben07]

Inline classes cannot be used from Java. You'll have to write wrapper methods that do not use inline classes in Kotlin to be used from Java

[Sylvain Patenaude]

Really?? Is this documented somewhere? That's a real bummer since the most of my functions use unsigned types, mostly UByteArray and UByte.

[diesieben07]

Well, Java does not understand inline classes, so they cannot be used safely from there.

[diesieben07]

This is documented here:
https://kotlinlang.org/docs/reference/inline-classes.html#mangling

[Sylvain Patenaude]

Ok. But let's say I need, conceptually, functions such as fun parseByteArray(array: UByteArray): SomeClass {}. How can I work around the inline class limitation? Is there a way to wrap the unsigned classes in a usable way?

[diesieben07]

Depends on how you want it to be represented in Java. If you want it to be a regular byte[] then you can write a Kotlin method which accepts ByteArray and converts it to UByteArray using toUByteArray().

[Sylvain Patenaude]

Yeah, I'll try something like that. Thanks! I assume the conversions functions (toByte(), toUByte(), toByteArray(), toUByteArray) are smart enough to handle negative signed bytes and all that, right?

[diesieben07]

They will interpret the signed bytes as unsigned. -1 will turn into 255, for example.