Restore 32-bit support in Java Coder

[andriydruk]

No description provided.

[ynnadrules]

@andriydruk The changes you have made here seem to work except when it comes to doubles. Doubles coming back from the swift side are NaN on the kotlin side. Any ideas?

Ex:

publicstructProgress:Codable{publicletcurrent:Intpubliclettotal:Intpublicvarprogress:Double{returnDouble(current)/ Double(total)}}

@SwiftValue
classProgress private constructor() {
@get:SwiftGetter
val percentage:Doubleexternal get
}
val foo = bar.progress
foo.percentage ==Double.NaN// percentage is NaN

[ynnadrules]

@andriydruk I was going to add a failing test case in swift-java-codegen but all you need to do is point that sample package's swift-java-coder dependency to this dev/32-bit-support branch and run the tests in DoubleTests.java. Unrelated note: the params for the actual and expected values in all the assert* calls are flipped 😄

[andriydruk]

I've just checked DoubleTest everything works fine. I've just added x86 CI, all tests are green readdle/swift-java-codegen#31
Could you add your test that fails on x86?

[ynnadrules]

@andriydruk Hey, well I think due to the latest changes you just pushed to this branch, the test are all green for me too! Before, some of the tests in DoubleTests.java from swift-java-codegen were failing when using the 32-bit-support branch of swift-java-coder, like testZero() and testEncode().

So what do you ultimately think the issue was behind doubles becoming NaNs? The testZero() scenario was simply bridging 0.0 which (i believe) doesn't go through the encoding/decodable closures that are registered in JavaCoderConfig.swift, but instead, via JavaObjectEncoder, has javaPrimitive() called on the Double.

Anyway, thanks so much for providing a fix for this!

[andriydruk]

Ok, looks that everything now works fine
I will merge this PR to dev/kotlin-support and merge readdle/swift-java-codegen#31 after branch update

[ynnadrules]

@andriydruk It unfortunately turns out the issue is still happening. All the tests in DoubleTests.swift that were failing before were fixed with your last change, but in some cases the NaN issue is still happening for us. Here's a branch in our fork of swift-java-codegen with the bug test case: https://github.com/heliumfoot/swift-java-codegen/tree/bug/32-bit-double-nan-bug

The example is a type that represents progress and has a a computed property that returns a percentage. That percentage is a Double and when you use that property on the android side it is NaN. Maybe the issue is something obvious that I am not seeing?

Here is the test run: https://github.com/heliumfoot/swift-java-codegen/runs/2223011181?check_suite_focus=true

[andriydruk]

Hi, @ynnadrules thank you

We should definitely start from PR next time and not guessing what broken.
Yes, a problem occurs on a 32-bit device. I've just found an issue in the compiler and fixed it readdle/swift-java-codegen@c62a089

Could I use tests from your fork in our repo?

[ynnadrules]

Hey @andriydruk, yes feel free to use the tests. I unfortunately had to revert to the java-based bridging during these two weeks due to our project's timeline and many of our stakeholders having 32-bit based android phones. But hopefully now we have a path forward with the kotlin-based bridging. I'll test it out soon.

Out of curiosity, is Readdle using the kotlin-based bridging for their released apps already or just internally or on beta releases?

thanks again @andriydruk.

[andriydruk]

We still using Java-bridging in Spark and Kotlin-briding in some internal tools.
But we have the plan to migrate all our Spark bridging code to Kotlin in the next few weeks

We really appreciate your help in the stabilization code-gen 🙏

PS: I pushed your tests to readdle/swift-java-codegen#31