jextract/jni: Add basic support for generic types

[sidepelican]

Purpose

This PR introduces basic support for accessing generic Swift types from Java.
As this is the initial step, the functionality is currently limited.

Specifically, the following are not supported in this PR:

• The Java-side wrappers do not yet have generic signatures.
• No access to static members. (Since there is no mechanism to specify type parameters from Java yet.)
• No access to members using type parameters

Implementation

The general strategy follows the direction discussed in this issue comment.

In this implementation, the Swift metatype is stored as a field within the Java wrapper class.
When a function is called, this metatype is passed as an argument to the native function.

Regarding the usage of the metatype, I have adopted a different approach than the one originally mentioned in the issue.
When a type is generic, the generator now produces an "opener protocol".
This is a technique to handle the Self type correctly from a metatype. By conforming the original type to this opener protocol, we can indirectly extract and utilize the type parameters within Swift.

public struct MyID<T> {
  public var rawValue: T
  public var description: String {
    "\(rawValue)"
  }
}

protocol _MySwiftLibrary_MyID_opener {
  static func _get_description(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, self: jlong) -> jstring?
  ...
}

extension MyID: _MySwiftLibrary_MyID_opener {
  static func _get_description(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, self: jlong) -> jstring? {
    assert(self != 0, "self memory address was null")
    let selfBits$ = Int(Int64(fromJNI: self, in: environment))
    let self$ = UnsafeMutablePointer<MyID>(bitPattern: selfBits$)
    guard let self$ else {
      fatalError("self memory address was null in call to \(#function)!")
    }
    return self$.pointee.description.getJNIValue(in: environment)
  }
  ...
}

@_cdecl("Java_com_example_swift_MyID__00024getDescription__JJ")
public func Java_com_example_swift_MyID__00024getDescription__JJ(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, self: jlong, selfType: jlong) -> jstring? {
  let selfTypeBits$ = Int(Int64(fromJNI: selfType, in: environment))
  guard let selfType$ = UnsafeRawPointer(bitPattern: selfTypeBits$) else {
    fatalError("selfType metadata address was null")
  }
  let openerType = unsafeBitCast(selfType$, to: Any.Type.self) as! (any _MySwiftLibrary_MyID_opener.Type)
  return openerType._get_description(environment: environment, thisClass: thisClass, self: self)
}

Why not use the original pattern?

This is because the original pattern cannot handle certain cases successfully. It cannot expand when there are multiple type parameters and constraints.

Others

The following functions cause branching in code generators based on whether they are generic or not:

• long $typeMetadataAddress()
• Runnable $createDestroyFunction()
• Discriminator getDiscriminator()

Similar to the refactoring in #567 for toString, I plan to register these as SynthesizedAPI to remove this redundancy. However, to avoid over-complicating this PR, I have deferred that refactoring to a future update.

[ktoso]

👍

[ktoso]

Let's include the selfType$ now as well

[ktoso]

Suggested change

	static func _get_description(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, self: jlong) -> jstring?
	static func _get_description(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, selfPointer: jlong) -> jstring?

sorry to be annoying about the selfPointer every time 😉

I don't want it to be confusing when we see a self it should be the object and the selfPointer should be the jlong or other pointer repr

[sidepelican]

I see. I don't have a strong preference, so I think selfPointer is fine as well.

The variable name self originates from this location:

swift-java/Sources/JExtractSwiftLib/JNI/JNISwift2JavaGenerator+NativeTranslation.swift

Line 55 in da7d0a5

parameterName: selfParameter.parameterName ?? "self",

Changing this to selfPointer would require updating a large number of existing tests.
Would you still like me to proceed with the change?

[ktoso]

Yeah let's bite the bullet, we can do it in a separate PR.

This is looking good, happy to land it after some nitpicks

[ktoso]

Please document what this is for

[ktoso]

Suggested change

	public long selfTypePointer;
	public final long selfTypePointer;

If making them public please make them final

[sidepelican]

OutSwiftGenericInstance is a temporary container used for receiving multiple return values.

Both selfPointer and selfTypePointer are updated from the Swift side using JNI's SetLongField.
While JNI can technically bypass the final modifier to modify fields, I'm concerned that JIT optimizations might lead to unexpected behavior if the compiler makes incorrect assumptions about these values being constant.

Should I add the final modifier ?

[ktoso]

Suggested change

	public long selfPointer;
	public final long selfPointer;

If making them public please make them final

[ktoso]

This deserves some more docs about how we import it, since we drop the generic from the signature we should explain this -- but for simple things I thikn we'll be able to pull off doing a generic on the Java side tbh right?

[sidepelican]

I wrote documentation to make it clearer what gets exported and what doesn't.

016766b

[ktoso]

I'm happy to merge this as a first step towards generics support :) Just the few nitpicks please

[ktoso]

I just fixed the android CI, a new run should pass