MethodWrapper: Get rid of reflection and dynamic code

[iansmirlis]

Rewrite MethodWrapper in a way to support build time generated code instead of dynamic code.

#1 (comment)

[pavelsavara]

One scenario, where this is not easy is marshaling of interface implementation, in case when you don't have exactly one matching class for the proxy. You have to create proxy which implements superset of the interfaces of the proxied type. And that's dynamic problem at runtime.

We could discuss how important this scenario is, and maybe throw it under the bus.

[pavelsavara]

I mean

https://github.com/jni4net/jni4net/blob/ac2189c37253710e7b729797631419b0bf3b8559/jni4net.n/src/utils/Registry.resolve.cs#L35-L39

and

https://github.com/jni4net/jni4net/blob/ac2189c37253710e7b729797631419b0bf3b8559/jni4net.n/src/utils/Convertor.J2C.cs#L39

[prusovak2]

I'm sorry, but I don't understand the problem you are describing. Could you provide the example of Java code that will require dynamically generated proxy?

[pavelsavara]

We generated wrappers/proxies for IFoo and IBar interfaces at compile time. We give the .dll and the .jar wrappers to another developer. He knows nothing about jni4net. He will create implementation class in Java MyFooBar which implements both IFoo and IBar and sends the instance to C#. Which of the C# proxies/wrappers should we use to represent it on C# side ?

[prusovak2]

What does "he sends it" to C# mean in this case? I'm maybe completely off, because up this point I've only concidered C# -> Java direction of invocation, but doesn't sending something to C# mean returning it from Java method for which we have C# proxy? Because in that case we would know the interface type statically by the return type of the method.

[pavelsavara]

What does "he sends it" to C# mean in this case?
mean returning it from Java method for which we have C# proxy?

Yes it could be on return from C#->Java call

The signature would be IFoo createFoo() and the dynamic type of the instance would be MyFooBar (which is unknown at time when you generate code).

You are right that __IFooProxy is the default C# class to use. But since your running bridge process knows also about IBar type, it could possibly dynamically create type __IFooBarProxy. So that you can later cast it to IBar pass it back to Java on

void consumeBar(IBar b) wrapped method.

[prusovak2]

Thanks, now I undestand. My implemenation is miles away from considering this.

[pavelsavara]

Alternative to __IFooBarProxy runtime generated type is to create another instance. That requires helper method, now I remember I did that too.

https://github.com/jni4net/jni4net/blob/ac2189c37253710e7b729797631419b0bf3b8559/jni4net.n/src/Bridge.CLR.convertor.cs#L77

This breaks reference equals on the proxy instances. I don't rememeber anymore if jni4net creates proxy instances per call of if I have some cache for it.

[iansmirlis]

One scenario, where this is not easy is marshaling of interface implementation, in case when you don't have exactly one matching class for the proxy. You have to create proxy which implements superset of the interfaces of the proxied type. And that's dynamic problem at runtime.

We could discuss how important this scenario is, and maybe throw it under the bus.

Yeah this is tough. Given that the proxygen knows nothing about the superset classes, for the time-being I cannot think of anything better than reflection and runtime magic.

On the other hand though, I am not quite sure if this type of usage is in the scope of jni4net, meaning that proxy generation seems to be more like a step in the compilation process and ideally should be able to know everything about every used type.

However, it's too early to have well-educated opinion on this.