Collect overridden Java methods in JCW #985
Merged
Conversation
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
jonpryor
reviewed
May 16, 2022
| } | ||
| } | ||
|
|
||
| public List<string> OverriddenMethods => overriddenMethods; |
Contributor
There was a problem hiding this comment.
I think this should be ICollection<string>, or maybe ReadOnlyList<string>. FxDG suggests avoiding List<T> for properties, as it's not easy to make changes later.
Naming: suggest OverriddenMethodDescriptions, as this is the names, not the methods themselves.
Instead of string, should a struct or class be used? I'm not sure how "future proof" a type-name:method-name string convention will work, and it might be useful in the future to store/retain type & method ids, etc.
Contributor
|
Something appears to be "wrong" with the Mac - Mono bot, e.g. This might be a sign we need to stop using @jpobst: thoughts? |
Marshal methods generator in Xamarin.Android needs to know which Java methods in which types are overridden by the application. Package name, method name and signature are all require to generate correct name of the native symbol which will be found by JNI at the run time.
grendello
force-pushed
the
marshal-methods
branch
from
fd00686 to
d8307f8
Compare
Contributor
|
WIP commit message: [Java.Interop.Tools.JavaCallableWrappers] Collect overriden methods (#985)
We are prototyping a new marshal method generator in xamarin-android
which emits native functions with [JNI native method names][0].
This would remove the need for `Runtime.register()` invocations from
Java Callable Wrappers and all the related Reflection-heavy marshal
method registration code; see 4787e017 for some details for how the
current Reflection approach works.
In order to emit native functions which have the correct names, we
need to know additional information, such as the package name and
type name of the Java `native` method, method signature, etc.
Update `JavaCallableWrapperGenerator` to collect this additional
information, making it available via a new
`JavaCallableWrapperGenerator.OverriddenMethods` property.
[0]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Marshal methods generator in Xamarin.Android needs to know
which Java methods in which types are overridden by the application.
Package name, method name and signature are all require to generate
correct name of the native symbol which will be found by JNI at the
run time.