[Java.Base-Tests] Test Java-to-Managed invocations for Java.Base

[jonpryor]

Commit bc5bcf4 (Desktop Java.Base binding) had a TODO:

~~ TODO: Marshal Methods ~~

Marshal methods are currently skipped. Java-to-managed invocations
are not currently supported.

No marshal methods means no facility for Java-to-managed invocations.

Add a new tests/Java.Base-Tests unit test assembly, and test
Java-to-managed invocations.

This requires touching and updating ~everything. 😅

Update Java.Interop.dll to contain a new
Java.Interop.JniMethodSignatureAttribute custom attribute.

Update generator to begin emitting [JniMethodSignature] on bound
methods. This is necessary so that jcw-gen knows the JNI method
signature of Java methods to emit. As part of this, remove the
JniTypeSignatureAttr type added in bc5bcf4; trying to follow the
JniTypeSignatureAttr pattern for JniMethodSignatureAttr would
make for more intrusive code changes. Instead, "re-use" the existing
RegisterAttr type, adding a RegisterAttr.MemberType property so
that we can select between Android [Register] output vs. "Desktop"
[JniTypeSignature] and [JniMethodSignature] output. This in turn
requires updating many generator-Tests artifacts.

Update Java.Interop.Tools.JavaCallableWrappers to look for
Java.Interop.JniTypeSignatureAttribute and
Java.Interop.JniMethodSignatureAttribute. This allows
jcw-gen Java.Base-Tests.dll to generate Java Callable Wrappers for
Java.BaseTests.MyRunnable.

Update Java.Interop.Export.dll so that MarshalMemberBuilder
doesn't use Expression.GetActionType() or
Expression.GetFuncType(), as .NET doesn't support the use of
generic types in Marshal.GetFunctionPointerForDelegate().
Instead, we need to use System.Reflection.Emit to define our own
custom delegate types.

Comparison with Android

Android bindings (both Classic Xamarin.Android and
.NET SDK for Android) use generator-emitted "connector methods"
which are specified in the [Register] attribute (see also 99897b2):

namespace Java.Lang {
    [Register ("java/lang/Object" DoNotGenerateAcw=true)]
    partial class Object {
        [Register ("equals", "(Ljava/lang/Object;)Z", "GetEquals_Ljava_lang_Object_Handler")]
        public virtual unsafe bool Equals (Java.Lang.Object? obj)
            => …

        static Delegate GetEquals_Ljava_lang_Object_Handler()
            => JNINativeWrapper.CreateDelegate((_JniMarshal_PPL_Z) n_Equals_Ljava_lang_Object_);
        static bool n_Equals_Ljava_lang_Object_ (IntPtr jnienv, IntPtr native__this, IntPtr native_obj)
            => …
    }
}

jcw-gen emits the "connector method" into the resulting
Java Callable Wrappers for appropriate subclasses:

String __md_methods =
    "n_equals:(Ljava/lang/Object;)Z:GetEquals_Ljava_lang_Object_Handler\n";

At runtime, AndroidTypeManager.RegisterNativeMembers() will lookup
Object.GetEquals_Ljava_lang_Object_Handler() and invoke it.
The returned Delegate instance is provided to
JNIEnv::RegisterNatives().

The problem with this approach is that it's inflexible: there is no
way to participate in the "connector method" infrastructure to alter
marshaling behavior. If you need custom behavior, e.g.
Android.Graphics.Color customizations, you need to update
generator and rebuild the binding assemblies.

(This has been "fine" for the past 10+ years, so this hasn't been a
deal breaker.)

For Java.Base, @jonpryor wants to support the custom marshaling
infrastructure introduced in 77a6bf8. This would allow types to
participate in JNI marshal method ("connector method") generation
at runtime, allowing specialization based on the current set of
types and assemblies.

This means we don't need to specify a "connector method" in
[JniMethodSignatureAttribute], nor generate them.

namespace Java.Lang {
    [JniTypeSignatureAttribute("java/lang/Object", GenerateJavaPeer=false)]
    partial class Object {
        [JniMethodSignatureAttribute("equals", "(Ljava/lang/Object;)Z")]
        public virtual unsafe bool Equals (Java.Lang.Object? obj)
            => …

        // No GetEquals_Ljava_lang_Object_Handler()
        // No n_Equals_Ljava_lang_Object_()
    }
}

This should result in smaller binding assemblies.

The downside is that runtime costs increase, significantly.
Instead of looking up and invoking a "connector method", the method
must be generated via System.Linq.Expressions expression trees,
then compiled into IL, then JIT'd, all before it can be used.

We have no timing data to indicate how "bad" this overhead will be.

As always, the hope is that tools/jnimarshalmethod-gen (176240d)
can be used to get the "best of both worlds": the flexibility of
custom marshalers, without the runtime overhead. But…

• JNI Marshal Method Generation, Registration #14
• Port jnimarshalmethod-gen.exe to net5 #616

At this point in time, jnimarshalmethod-gen cannot work under
.NET 6. This will need to be addressed in order for custom marshalers
to be a useful solution.

Java.Base will use "connector method"-less bindings to act as a
"forcing function" in getting jnimarshalmethod-gen working in .NET.

[jonathanpeppers]

Should the switch here have a name like --java-peer-style=?

[jonpryor]

The intent was to be consistent with generator, so you would use generator --codegen-target=JavaInterop1 … ; jcw-gen --codegen-target=JavaInterop1 ….

That might not actually be useful, especially considering that MSBuild tasks should (eventually) be provided, not command-line tools…

[jonpryor]

…and to verify that I didn't accidentally break Xamarin.Android: dotnet/android#6984

[jonpryor]

Of particular note is that this change updates XAJavaInterop1
output to have RegisterAttribute.DoNotGenerateAcw=true on bound
interfaces

…which promptly broke the xamarin-android build: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6110214&view=logs&jobId=a1070d6b-7539-53cb-46be-b3395553b4a7&j=96fd57f5-f69e-53c7-3d47-f67e6cf9b93e&t=65256bb7-a34c-5353-bc4d-c02ee25dc133

…
error : CannotChangeAttribute : Attribute 'Android.Runtime.RegisterAttribute' on 'Org.W3c.Dom.INamedNodeMap' changed from '[RegisterAttribute("org/w3c/dom/NamedNodeMap", "", "Org.W3c.Dom.INamedNodeMapInvoker")]' in the contract to '[RegisterAttribute("org/w3c/dom/NamedNodeMap", "", "Org.W3c.Dom.INamedNodeMapInvoker", DoNotGenerateAcw=true)]' in the implementation.
…
error : Total Issues: 969 

Looks like I can't make that change.

[jpobst]

Do we need to update the Linker to remove these attributes? Otherwise the size of binding assemblies may go up, resulting in larger .apks.

[jonpryor]

If these attributes were to be used in Android, yes we'd want to remove them.

However, unless someone is using the JavaInterop1 codegen target -- which is highly unlikely, considering it doesn't really work right (as evidenced by the fact that the Java.Base binding is excluding almost everything) -- then there won't be any attributes to remove.

This is thus a more "eventually…" thing to do, rather than something to worry about now. (.NET 8 timeframe? Maybe? Perhaps?)

[jpobst]

👍 Got confused with XAJavaInterop1.