Classes with a type parameter fail to compile

[abdulowork]

I searched through the issues, but couldn't find an explicit issue about the missing support for generics. In particular if you have a public class such as:

public class Foo<T> {
    public init() {}
}

in Samples/SwiftJavaExtractFFMSampleApp/Sources/MySwiftLibrary/Foo.swift, then the Swift wrappers compilation currently fails with:

error: generic parameter 'T' could not be inferred
 26 | @_cdecl("swiftjava_getType_MySwiftLibrary_Foo")
 27 | public func swiftjava_getType_MySwiftLibrary_Foo() -> UnsafeMutableRawPointer /* Any.Type */ {
 28 |   return unsafeBitCast(Foo.self, to: UnsafeMutableRawPointer.self)
    |                        |- error: generic parameter 'T' could not be inferred
    |                        `- note: explicitly specify the generic arguments to fix this issue

[sidepelican]

@ktoso I’ve outlined a potential approach to resolve this issue. I’d appreciate your feedback on the following plan.

Investigation of Existing Interoperability

I first looked into how generics are handled in existing Swift interoperability layers:

• Objective-C: Generic types are not exported at all.
• C++: Only struct types support generics; class types do not. The implementation directly calls functions using mangled Swift symbols according to the calling convention. It leverages advanced C++ template features to implement copy semantics that match Swift’s generic logic. It allows Swift-derived types and some primitives as generic parameters, with static enforcement via templates (invalid types cause compilation errors).

Proposed Strategy for swift-java

While I would like to follow the C++ implementation's lead, it is difficult for two reasons:

1. jextract cannot retrieve mangled names.
2. Java generics are more limited compared to C++ templates.

Therefore, I believe we need a different approach. I propose the following phased improvements:

---

1. Retaining Metatypes for Type Parameters

This phase focuses on fixing the current error:

error: generic parameter 'T' could not be inferred
 26 | @_cdecl("swiftjava_getType_MySwiftLibrary_Foo")
 27 | public func swiftjava_getType_MySwiftLibrary_Foo() -> UnsafeMutableRawPointer /* Any.Type */ {
 28 |   return unsafeBitCast(Foo.self, to: UnsafeMutableRawPointer.self)
    |                        |- error: generic parameter 'T' could not be inferred
    |                        `- note: explicitly specify the generic arguments to fix this issue

We need a way to restore concrete Swift types from pointers received from Java.

I propose to modify the Java wrapper classes to store a pointer to the type parameter's metatype.
With this pointer, we can restore the concrete type on the Swift side.

public func MyBox_getMyValue_bridge(
    self: Int,
    metadataPointer: Int,
) -> Any {
    func open<T>(type: T.Type) -> Any {
        let self$ = UnsafeMutablePointer<MyBox<T>>(bitPattern: self)!
        return self$.pointee.myValue // Accessing the original type
    }
    let metatype = unsafeBitCast(metadataPointer, to: Any.Type.self)
    return open(type: metatype) // Implicit open existential
}

If generic values are required for arguments or return values, they will need proper wrapping. Since generic return values are not currently supported, I will set that case aside for this phase.

At this stage, Java wrapper classes will not yet reflect these type parameters.

---

2. Representing Type Parameters in Java

I see two potential directions for the Java-side representation:

2-A. Adding Type Parameters to Java Wrapper Classes

public final class MyBox<T> implements JNISwiftInstance { ... }

This is intuitive but has many challenges.

Java cannot constrain T as strictly as C++ templates can.
A type available for T must be one that can provide the corresponding Swift metatype.

Additionally, Java generics do not support primitives.
This means a Swift Int (usually long) would need to be Long. Having different mapping rules depending on whether a type is used as a value or a type parameter adds significant complexity.

2-B. Generating Unique Java Wrappers for Each Concrete Type

// MyBox<Int>
public final class MyBox_Int implements JNISwiftInstance { ... }

// MyBox<MyClass>
public final class MyBox_MyClass implements JNISwiftInstance { ... }

This is simpler, but it prevents Java users from freely combining types.
It also risks a "combinatorial explosion" of generated code if we eventually want to support functions with multiple generic arguments.

---

Short-term Goal

I would like to start with phase 1.
Phase 2 requires further design and is premature for now.
Does this approach sound reasonable to you?

[ktoso]

That sounds about right, our 2 goal is going to be A for sure, even if we might have to rely a bit on runtime checks (on Swift side) for what we can't express in Java. Keep in mind that we can extend Swift if we find ourselfes blocked e.g. with ways to obtain metadata or mangled names etc. We have experimented in this past with swift interfaces exposing mangled names of things, so we could investigate what would be helpful here as well.

Starting with 1 sounds good as well, thanks for looking into it!

[sidepelican]

Thank you for your review.
I see that improvements to Swift itself are being considered as well. I'll keep that in mind.
I'll start working on phase 1.