Initialising with ByteArray differs from java's BigInteger

[fullkomnun]

Describe the bug
For a specific overflow byte array, initialising creates a different value comapred to java's BigInteger.

To Reproduce
Steps to reproduce the behavior:
sample unit test:

@Test
fun foo() {
    val bytes = byteArrayOf(-128, 0, 0, 0, 0, 0, 0, 0) // bytes: [-128, 0, 0, 0, 0, 0, 0, 0]
    val javaBig = BigInteger(1, bytes) // javaBig: "9223372036854775808"
    val kotlinBig = IonSpinBigInteger.fromByteArray(bytes, Sign.POSITIVE) // bytes: [-128, 0, 0, 0, 0, 0, 0, 0], kotlinBig: "0"
    Assert.assertArrayEquals(javaBig.toByteArray(), kotlinBig.toByteArray()) // javaBig: "9223372036854775808", kotlinBig: "0"
}

Expected behavior
Expected same numeric value as with java's BigInteger but it differs and this test fails.

Platform
JVM

Additional context
Although i encountered this issue for these specific values, there obviously could be more and randomised testing can help here.

[ionspin]

@fullkomnun You might be interested to look into https://github.com/ionspin/kotlin-multiplatform-libsodium and https://github.com/ionspin/kotlin-multiplatform-crypto for crypto multiplatform needs. They are not remotely ready for production use at the moment, but you might point out what you need in this early development stage of these two libraries.

[fullkomnun]

@fullkomnun You might be interested to look into https://github.com/ionspin/kotlin-multiplatform-libsodium and https://github.com/ionspin/kotlin-multiplatform-crypto for crypto multiplatform needs. They are not remotely ready for production use at the moment, but you might point out what you need in this early development stage of these two libraries.

Thanks, will take a look.
One of my next goals is having a pure Kotlin multiplatform implementation of ECDSA (mainly with Ethereum's SECP256K1 curve) and I will be using 'kotlin-multiplatform-bignum' for that. I consider porting of that pure java implementation.

[ionspin]

@fullkomnun Just be aware that Kotlin Native (and bignum itself) can be very slow, you might want to use expect/actual mechanism of Kotlin Multiplatform and then use native library when necessarily.

Kotlin native should get faster as it matures though, and bignum has a native version tentatively planned in the future.

[fullkomnun]

@fullkomnun Just be aware that Kotlin Native (and bignum itself) can be very slow, you might want to use expect/actual mechanism of Kotlin Multiplatform and then use native library when necessarily.

Kotlin native should get faster as it matures though, and bignum has a native version tentatively planned in the future.

The main targets for now are JVM and nodeJS.
The pure kotlin implementation approach vs platform specific (optimised?) implementation is indeed interesting.
BTW, when do you plan to release the next version of bugnum?
We will use it for adoption in KEthereum.

[ionspin]

I'm waiting for the build to finish for the latest merge and then I'll get to publishing a new release, all in all should be available by the end of the day if Maven Central nexus repo doesn't give me trouble like last time.