Skip to content
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

XA Binding ambiguous reference #344

Open
erikpowa opened this issue Jul 3, 2018 · 3 comments
Open

XA Binding ambiguous reference #344

erikpowa opened this issue Jul 3, 2018 · 3 comments
Labels
enhancement Proposed change to current functionality generator Issues binding a Java library (generator, class-parse, etc.)

Comments

@erikpowa
Copy link

erikpowa commented Jul 3, 2018

Having interfaces (generated) like this

public interface IInterface3 : { void Close(); }
public interface IInterface2 : { void Close(); }
public interface IInterface1 : IInterface2, IInterface3 {}

The IInterface1 's invoker generated code with ambiguous reference:

static void n_Close (IntPtr jnienv, IntPtr native__this)
{
	global::IInterface1 __this = global::Java.Lang.Object.GetObject<global::IInterface1> (jnienv, native__this, JniHandleOwnership.DoNotTransfer);
	__this.Close (); // problem is here, it should be IInterface2 or IInterface3
}

There is two scenarios in this situation:

  1. If both interface comes from MonoAndroid, you'll have no solution for this and have implement everything from scratch, manually.
  2. One of the interfaces is generated, so you can just remove the specific member from the interface. (which is clearly a bad solution even if the interface implementation is private)

(ps renaming the Close would not help, since the generator will create 2 same named pointer to the method:

IntPtr id_close; // this is gonna be duplicated anyway
public unsafe void Close ()
{
	if (id_close == IntPtr.Zero)
		id_close = JNIEnv.GetMethodID (class_ref, "close", "()V");
	JNIEnv.CallVoidMethod (((global::Java.Lang.Object) this).Handle, id_close);
}
@erikpowa erikpowa closed this as completed Jul 9, 2018
@mattleibow mattleibow reopened this Aug 6, 2019
@mattleibow
Copy link
Member

Why did you close this issue?

@mattleibow
Copy link
Member

mattleibow commented Aug 6, 2019

One workaround can be to add the close method to the interface using <add-node>.

@mattleibow
Copy link
Member

mattleibow commented Aug 6, 2019

Based on some discussion, it seems there is a bit more that might be ambiguous. For example, assume this C# class:

class Whatever : Java.Lang.Object, IInterface1, IInterface2, IInterface3 {
    void IInterface1.Close() { /* ... */}
    void IInterface2.Close() { /* ... */}
    void IInterface3.Close() { /* ... */}
}

Things will not work as expected. There is no guarantee which Java method will actually be invoked, when Java does a value.close() invocation! Or we might have errors in JNIEnv.RegisterJniNatives(). I’m 90% sure that’ll result in us re-registering close() 3 times. Will that error? Will it register the first function pointer? the last? ¯\_(ツ)_/¯
- @jonpryor

@jpobst jpobst added enhancement Proposed change to current functionality generator Issues binding a Java library (generator, class-parse, etc.) labels Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Proposed change to current functionality generator Issues binding a Java library (generator, class-parse, etc.)
Projects
None yet
Development

No branches or pull requests

3 participants