jextract/jni: Support non-JavaBoxable types in Dictionary#754
Open
sidepelican wants to merge 27 commits into
Open
jextract/jni: Support non-JavaBoxable types in Dictionary#754sidepelican wants to merge 27 commits into
sidepelican wants to merge 27 commits into
Conversation
Contributor
Author
|
Note:: Tuples aren't supported in this PR yet. |
ktoso
reviewed
May 15, 2026
| 1: Fish(name: "salmon"), | ||
| 2: Fish(name: "clownfish"), | ||
| ] | ||
| } |
|
|
||
| import SwiftJava | ||
|
|
||
| public protocol JextractedTypeBridge: JobjectBridge { |
Collaborator
There was a problem hiding this comment.
I like the idea, but since it's pretty tricky, i'd like some docs how this is used here please
|
|
||
| public static func fromJavaObject(_ obj: jobject?, in environment: JNIEnvironment) -> SwiftType { | ||
| guard let obj else { | ||
| fatalError("fromJavaObject received a null Java object") |
Collaborator
There was a problem hiding this comment.
Maybe include the jclass as we crash here, so we at least know what type it was?
| fromJNI value: jlong, | ||
| in environment: JNIEnvironment, | ||
| elementBridge: ElementBridge.Type | ||
| ) where ElementBridge.SwiftType == Element { |
Collaborator
|
I'll review this some more later, gotta head offline soon but I like the overall approach, this looks pretty good already 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Currently,
Dictionaryonly supports types that conform toJavaBoxable. This limitation prevents the use of dictionaries with custom or generated types, such as[Int: Fish].Solution
I have introduced the
JobjectBridgeprotocol, which allows us to define custom conversion logic for types when interacting with Java viajobject.JavaBoxabletypes are handled through a genericJavaBoxableBridge<T: JavaBoxable>.Alternatives Considered
1. Type-specific native functions
Using dedicated native functions for each type to avoid
jobjectwould be ideal, as it could leverage the existingtranslateResultmechanism and potentially reduce JNI overhead.However, I couldn't find a viable way to implement this.
2. Direct protocol conformance
I considered having types conform directly to
JobjectBridge.However, this is problematic for classes with inheritance, as Swift does not allow a type to conform to the same protocol multiple times (which would be necessary at different levels of a class hierarchy). Introducing separate Bridge types effectively bypasses this limitation.