Skip to content

Conversation

@madsodgaard
Copy link
Contributor

@madsodgaard madsodgaard commented Nov 28, 2025

environment.FindClass does not work when ran on native threads, such as is in the case of when we bridge async functions. As that function uses the caller class loader (which of course is not the application loader in native threads)

Therefore, we need the application class loader in order to cache non-system classes. As recommended in the Android docs, we store the application class loader on JNI_OnLoad, and use that to reference any classes. We also need this JNI_OnLoad in the future to fix #419 - so this is a nice start, but this PR does not fix that issue.

This is needed to make #462 work

@madsodgaard madsodgaard requested a review from ktoso November 29, 2025 07:27
@ktoso
Copy link
Collaborator

ktoso commented Nov 29, 2025

Lgtm, we may want to consider making thr init throwing but that may be annoying for now. Class not found do happen and perhaps should not crash the whole process tbh, depending what were tryint to find

self.javaObjectHolder = nil
} else {
// Clear any ClassNotFound exceptions from FindClass
environment.interface.ExceptionClear(environment)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right, good catch

/// An optional reference to a java object holder
/// if we cached this class through the class loader
/// This is to make sure that the underlying reference remains valid
nonisolated(unsafe) private let javaObjectHolder: JavaObjectHolder?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was the nonisolated unsafe necessary actually?

@ktoso ktoso merged commit 67c20f7 into swiftlang:main Dec 1, 2025
48 checks passed
@madsodgaard madsodgaard deleted the jni-caching branch December 2, 2025 09:14
ktoso added a commit to ktoso/swift-java that referenced this pull request Dec 4, 2025
Co-authored-by: pelekon <13712101+pelekon@users.noreply.github.com>
Co-authored-by: Konrad `ktoso` Malawski <konrad_malawski@apple.com>
Co-authored-by: Bartłomiej Bukowiecki <pelekon@users.noreply.github.com>
Fix `allowGlobalAutomatic` mode for interfaces (swiftlang#466)
Fix JNI caching for native threads (swiftlang#464)
fix extensions (swiftlang#473)
fix protocols that return java classes. (swiftlang#479)
ktoso added a commit that referenced this pull request Dec 4, 2025
* config: log-level should encode as string

* Properly handle nested directories of Swift Sources in jextract

* wip

* fix test and cleanup (#1)

Co-authored-by: pelekon <13712101+pelekon@users.noreply.github.com>
Co-authored-by: Konrad `ktoso` Malawski <konrad_malawski@apple.com>
Co-authored-by: Bartłomiej Bukowiecki <pelekon@users.noreply.github.com>
Fix `allowGlobalAutomatic` mode for interfaces (#466)
Fix JNI caching for native threads (#464)
fix extensions (#473)
fix protocols that return java classes. (#479)

---------

Co-authored-by: Mads Odgaard <mads@madsodgaard.com>
Co-authored-by: pelekon <13712101+pelekon@users.noreply.github.com>
Co-authored-by: Bartłomiej Bukowiecki <pelekon@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

swift-java does not work on Android API 28-30, due to missing JavaVM JNI symbols

2 participants