-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/mobile: make RunOnJVM available #26815
Comments
What is your use case? If you have any kind of Java code in your app, you can call into C through JNI and attain a JNIEnv pointer (and through that, a JavaVM pointer) that way. |
https://github.com/hajimehoshi/ebiten/blob/master/internal/devicescale/impl_android.go Actual usecase to call To call JNI functions, |
Change https://golang.org/cl/127758 mentions this issue: |
Is CL 127758 enough to solve your issue? |
Yes, this would solve our problems perfectly! |
@eliasnaur Great! I'm porting a game to Android, too. JNI interface is heavily used in my App. With RunOnJVM we can implement most of the Android functions. |
@eliasnaur this is only available for app, not for gobind libraries:( |
CL 122897 changed the visibility of the global JavaVM, JNIEnv and android.context.Context variables to be internal to gomobile. However, users of gomobile build programs used those internal variables to access Java API through Cgo and JNI without Java code. Make an exported version of mobileinit.RunOnJVM available. This is quite possibly not the right API for this, but I don't have the bandwidth to design a better solution. On the other hand, without access to Java APIs, gomobile build programs are unfairly forced to add Java code where before there were no need. Fixes golang/go#26815 Change-Id: I655fb858ffff03a0d542aa9bf97eefc7a22dd5d0 Reviewed-on: https://go-review.googlesource.com/127758 Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
CL 122897 changed the visibility of the global JavaVM, JNIEnv and android.context.Context variables to be internal to gomobile. However, users of gomobile build programs used those internal variables to access Java API through Cgo and JNI without Java code. Make an exported version of mobileinit.RunOnJVM available. This is quite possibly not the right API for this, but I don't have the bandwidth to design a better solution. On the other hand, without access to Java APIs, gomobile build programs are unfairly forced to add Java code where before there were no need. Fixes golang/go#26815 Change-Id: I655fb858ffff03a0d542aa9bf97eefc7a22dd5d0 Reviewed-on: https://go-review.googlesource.com/127758 Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
Before golang/mobile@56e3592, I was able to use an exported variable
current_vm
andcurrent_ctx
and call JNI functions. However, as these variables are no longer exported, it is impossible to access JNI functions. I admit accessingcurrent_vm
was not a good manner, but we rely on JNI functions heavily so we'd be really glad ifRunOnJVM
could be available (again?).For iOS, Objective-C functions are available via cgo, so there is no problem.
CC @eliasnaur
The text was updated successfully, but these errors were encountered: