Fix Int? argument issues on 32-bit environments

[sidepelican]

This PR fixes issues related to Int? arguments on 32-bit architectures.
The generated code contained numerous errors. (The failing CI run: https://github.com/swiftlang/swift-java/actions/runs/23786261629/job/69318324924 )

Background

During my investigation, I realized that the dynamic nature of Int.JNIType was significantly complicating the logic.
I have already submitted a PR to address this: swiftlang/swift-java-jni-core#16

In this PR, I have removed the various implementation pieces that were previously used to manually wrap Int into Int64.
With the unified JNIType, these are no longer necessary, and removing them resolves the original problem.

Verification

I have verified that the generated code compiles correctly for 32-bit by running the following command in SwiftJavaExtractJNISampleApp:

./gradlew assemble -PswiftSdk=armv7-unknown-linux-android28

While the compilation is successful, I do not have a 32-bit Android runtime environment, so I haven't been able to verify the actual execution results.

[sidepelican]

Sorry, I forgot to point this out; This PR requires swiftlang/swift-java-jni-core#16 to be merged first.

[ktoso]

I see... let's get some Android folks to chime in here, @madsodgaard has an interest in keeping those 32bit runtimes happy.

[marcprux]

If I'm reading this right, I do think it introduces peril for 32-bit platforms like armv7 on Android and other embedded devices.

In swiftlang/swift-java-jni-core#16 (comment) I suggest simply dropping Int conformance to JavaValue, since I don't think there is really any right way to do it for all platforms.

[ktoso]

Not supporting Int at all is not an option.

There's tons of Swift libs out there using Int and I don't want to be in the business of making idiomatic nice Swift libs have to start writing Int64 just "because swift-java can't handle it". Idiomatic swift libs must import properly, and especially with most systems being 64bit I don't think this is worth making life hard for everyone.

If I'm reading this right, I do think it introduces peril for 32-bit platforms like armv7 on Android and other embedded devices.

I'm not sure how to be honest, can you think of something? We're widening and swift jextract actually checks for overflows; manual users of jni-core may need to do the same, but I don't see it breaking anything 🤔

[finagolfin]

I do not have a 32-bit Android runtime environment, so I haven't been able to verify the actual execution results.

You do not need one, as most 64-bit Android devices support 32-bit execution, as does the emulator I believe. Simply run the 32-bit code and libraries in a 64-bit runtime and it should just work.

[ktoso]

The actual question here is what we "want" tbh... I could rebase the work but I'm not sure what we want to do here tbh still...

The OP is on leave for a while AFAIR, so we'd need to take this over.

[sidepelican]

The purpose of this PR is the following Swift code can be correctly handled in 32-bit env.

public func optionalPlatformDependentInt(input: Int?) -> Int? {
  input
}

At the time of submission, it caused several compilation errors (though I'm not sure about its current status).

[sidepelican]

And the root cause of this issue is swiftlang/swift-java-jni-core#16 , which needs to be resolved first.

[ktoso]

I’ll give all this another look, maybe it’s fine to just merge that one hmm