[Hello-NativeAOTFromJNI] Add NativeAOT sample

[jonpryor]

Instead of a managed app creating a Java VM and calling into Java, do the opposite: have a Java app call into Native Library built using NativeAOT, using [UnmanagedCallersOnly] to provide the entry points.

[jonpryor]

Alternatively, instead of introducing a "blittable method registration struct", we can instead use [UnmanagedFunctionPointer] to coerce NativeAOT to produce the required stubs:

diff --git a/src/Java.Interop/Java.Interop/ManagedPeer.cs b/src/Java.Interop/Java.Interop/ManagedPeer.cs
index eb43a9e8..044b9424 100644
--- a/src/Java.Interop/Java.Interop/ManagedPeer.cs
+++ b/src/Java.Interop/Java.Interop/ManagedPeer.cs
@@ -6,6 +6,7 @@ using System.Linq;
 using System.Linq.Expressions;
 using System.Reflection;
 using System.Reflection.Emit;
+using System.Runtime.InteropServices;
 using System.Runtime.Serialization;
 using System.Text;
 
@@ -50,6 +51,7 @@ namespace Java.Interop {
 		const string ConstructSignature = "(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)V";
 
 		// TODO: Keep in sync with the code generated by ExportedMemberBuilder
+		[UnmanagedFunctionPointer (CallingConvention.Winapi)]
 		delegate void ConstructMarshalMethod (IntPtr jnienv,
 				IntPtr klass,
 				IntPtr n_self,
@@ -177,6 +179,7 @@ namespace Java.Interop {
 
 		const   string  RegisterNativeMembersSignature  = "(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;)V";
 
+		[UnmanagedFunctionPointer (CallingConvention.Winapi)]
 		delegate void RegisterMarshalMethod (IntPtr jnienv,
 				IntPtr klass,
 				IntPtr n_nativeClass,

[jonpryor]

I'm uncertain how much I want to push unmanaged function pointers everywhere. I like the idea, but there are "unknown" implications, not least of which is JniNativeMethodRegistrationArguments.

[jonpryor]

Turns out that for NativeAOT, JniNativeMethodRegistrationArguments is unusable, because to get there we need to pass through Type.GetType("TypeToRegister, DeclaringAssembly"), which throws System.IO.FileNotFoundException: Could not resolve assembly 'DeclaringAssembly'..

Suggesting that there isn't actually any point in a blittable equivalent to JniNativeMethodRegistrationArguments, because we're gonna need to use Java_… native methods anyway. It's not optional for NativeAOT, it's required.

[jonpryor]

Implemented a "workaround" by adding a new JniRuntime.JniTypeManager.RegisterNativeMembers() overload which takes a ReadOnlySpan<char> instead of a Type, allowing subclasses to avoid the Type.GetType() invocation.

This has two implications:

1. Sample is able to "reasonably work" without implementing [UnmanagedCallersOnly(EntryPoint="Java_…")] marshal methods, so score one for simplicity, and
2. The question around a "blittable" equivalent of JniNativeMethodRegistrationArguments is reintroduced, as now it is plausible.

[jonpryor]

…and I in turn replaced the "new" (now removed) JniRuntime.JniTypeManager.RegisterNativeMembers() overload with an alternate approach involving JniRuntime.JniTypeManager.GetTypeFromAssemblyQualifiedName(), and "bulking up" the typemap dictionary within NativeAotTypeManager. This in no way verifies or removes the need for a blittable registration struct; it just further punts it down the line.

That said, a blittable struct would presumably be more efficient…

[jonpryor]

Should further extend sample to:

• Make use of Java.Base + jcw-gen for a custom Java.Lang.Object subclass
• Integrate jnimarshalmethod-gen

I suspect that jnimarshalmethod-gen (+changes) will be required in a NativeAOT environment, as "normal" Java.Base use in tests/Java.Base-Tests makes use of MarshalMemberBuilder, which requires System.Linq.Expressions, which is presumably unsupportable in a NativeAOT environment.

[jonpryor]

I previously wrote:

Should further extend sample to:

• Make use of Java.Base + jcw-gen for a custom Java.Lang.Object subclass
• Integrate jnimarshalmethod-gen

That was done, several commits ago, in: jonpryor@69c90ba

Fewer changes to jnimarshalmethod-gen were required than expected, actually; there was no need to implement [UnmanagedCallersOnly(EntryPoint="Java_…")] support, for example. We just needed to add [UnmanagedFunctionPointer] to the delegate types used by method registration.

Several incremental improvements since then.

[jonathanpeppers]

I think we might have to use:

[UnconditionalSuppressMessage ("Trimming", "IL2072")]

#pragma won't work at trimming time, because it's only present in C# source code.

[jonpryor]

What's odd is that I don't see an IL2072 warning at trimming time, so I'm not convinced that we need [UnconditionalSuppressMessage] here. The IL2072 warning ignored by this #pragma was a build warning within Java.Runtime.Environment.csproj, iirc.

[jonathanpeppers]

Do these actually need to be powershell or can they be script? I think script would be the same as cmd on Windows and bash on macOS.

[jonpryor]

I have no idea, I'm just going with @akoeplinger 's suggestion on Discord.

[jpobst]

We are only testing osx-x64 here. Should this PR work on Windows?

[jpobst]

Conditioning this off a display name seems brittle, we probably want:

condition: eq(variables['Agent.OS'], 'Darwin')

[akoeplinger]

script would work since the command is the same i.e. it doesn't matter whether cmd or bash is used but I agree that this should probably only execute on Mac.

[jonathanpeppers]

/cc @simonrozsival @vitek-karas

This is basically C# + Java "hello world" on NativeAOT.

[jpobst]

I guess the publish doesn't trigger WarnAsError, but note there are 11 warnings at the bottom of https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9093736&view=logs&j=4ab9874f-3b82-50ef-2a6b-4340d0043621&t=3f720a70-9e37-509d-b752-3ff7ec647839.

I'm not saying they need to be fixed, but we should be aware of them in case they are telling us that something hasn't been properly annotated for the linker to preserve them.

[jpobst]

We are only testing osx-x64 here. Should this PR work on Windows?

[jpobst]

Conditioning this off a display name seems brittle, we probably want:

condition: eq(variables['Agent.OS'], 'Darwin')

[jonpryor]

@jpobst asked:

We are only testing osx-x64 here. Should this PR work on Windows?

In theory, yes. In practice, it's never been run on Windows, so I have no idea. It'll certainly require a different $(RuntimeIdentifier) value, probably win-x64…

[jonpryor]

@jpobst: the PR now works on Windows.

[jonpryor]

Context: 28849ec1e6b2400576f4f2a0d1fe7aabfbda2269
Context: bc5bcf4f0ef07aab898f2643d2a25f66512d98ed
Context: 25850ba741b9e3d9dbda353c03b80f7ccb4def42
Context: 56955d9ad3952070de3bb1718375b368437f7427
Context: https://github.com/xamarin/java.interop/issues/1157
Context: c6c487b62dab4ffec45e61b09dd43afc89898caf
Context: https://github.com/xamarin/xamarin-android/commit/180dd5205ab270bb74bb853754665db9cb5d65f1

Commit 28849ec1 noted:

> [JNI][0] supports *two* modes of operation:
> 
>  1. Native code creates the JVM, e.g. via [`JNI_CreateJavaVM()`][1]
> 
>  2. The JVM already exists, and when Java code calls
>     [`System.loadLibrary()`][3], the JVM calls the
>     [`JNI_OnLoad()`][2] function on the specified library.
>
> [0]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html
> [1]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#creating_the_vm
> [2]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Runtime.html#loadLibrary(java.lang.String)
> [3]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNJI_OnLoad

Our existing unit tests, e.g. `tests/Java.Interop-Tests`, exercise
the first mode of operation.

The second mode of operation is how .NET Android executes.

Add `samples/Hello-NativeAOTFromJNI`, a new sample which exercises
the second mode of operation:

 1. `Hello-NativeAOTFromJNI` contains C# methods which use
    [`UnmanagedCallersOnlyAttribute`][4] to export `JNI_OnLoad()` and
    various other native symbols for JNI to execute.

 2. `dotnet publish Hello-NativeAOTFromJNI.csproj` will use
    [NativeAOT][5] to produce a native library which can be loaded
    and used by a desktop JVM.

 3. `Hello-NativeAOTFromJNI` references `Java.Base.dll` (bc5bcf4f),
     and contains a C# `Java.Lang.Object` subclass, which contains a
    `[JavaCallable]` method.

 4. `jcw-gen` is called during the build process to generate
    Java Callable Wrappers for (3), containing the `[JavaCallable]`
    method.

 5. `jnimarshalmethod-gen` (25850ba7) is called during the build
    process to generate marshal methods for (3), as `generator`
    output for JavaInterop1 doesn't contain marshal methods (unlike
    XAJavaInterop1, used by .NET Android), and NativeAOT doesn't
    support System.Reflection.Emit.

 6. The type in (3) is instantiated *from Java*, and Java invokes the
    `[JavaCallable]` method.

 7. `Hello-NativeAOTFromJNI` also contains Java code including a
    `main()` method (to start execution from Java)

Conceptually straightforward!

See `samples/Hello-NativeAOTFromJNI/README.md` for more details.


~~ `$(Standalone)`=true is now the default build config ~~

The `$(Standalone)` build config (c6c487b6) is now enabled by
default.  This means that neither `Java.Interop.dll` nor
`Java.Runtime.Environment.dll` *require* a `java-interop` native
library, which (1) was already the case for xamarin-android as of
xamarin/xamarin-android@180dd520, and (2) simplifies NativeAOT
support immensely.


~~ Avoid Adding Public API ~~

In order to avoid adding new public API to `Java.Interop.dll`, update
`Java.Interop.dll` to have `[InternalsVisibleTo]` for
`Java.Runtime.Environment.dll`.  This allows `JreTypeManager` to use
`JniRuntime.UseMarshalMemberBuilder`, without needing to worry about
`try`/`catch` blocks.

This in turn requires renaming `NativeMethods` within
`Java.Runtime.Environment.dll` to `JreNativeMethods`, as
`Java.Interop.dll` *also* has a `NativeMethods` type.


~~ NativeAOT Integration ~~

Conceptually straightforward, but not without lots of pitfalls.

In order for Java code to call into C# code, there must be a
Java Callable Wrapper, which contains Java `native` methods, and
those Java `native` methods must be *registered with Java* before
they are executed.

Method registration involves lots of delegates, which need to be
stored in the `JniNativeMethodRegistration.Delegate` field, of type
`System.Delegate`.

NativeAOT doesn't like this by default.  In order to convince
NativeAOT to support this, every delegate instance provided to
`JniNativeMethodRegistration.Delegate` must be of a delegate type
which has [`UnmanagedFunctionPointerAttribute`][6].  This coerces
NativeAOT to emit "stubs" for the referenced method, allowing things
to work with fewer changes.

Linux builds require `-Wl,-soname` to be set manually in order for
the resulting `.so` to work properly.


~~ Trimmer Warnings ~~

Fix additional trimmer warnings, a'la xamarin/java.interop#1157.

`Type.MakeGenericType()` needs to ensure constructors are preserved:

	src/Java.Interop/Java.Interop/JniRuntime.JniValueManager.cs(378): Trim analysis warning IL2068:
	  Java.Interop.JniRuntime.JniValueManager.<GetInvokerType>g__MakeGenericType|31_1(Type,Type[]):
	  'Java.Interop.JniRuntime.JniValueManager.<GetInvokerType>g__MakeGenericType|31_1(Type,Type[])' method return value does not satisfy
	  'DynamicallyAccessedMemberTypes.PublicConstructors', 'DynamicallyAccessedMemberTypes.NonPublicConstructors' requirements.
	  The parameter 'type' of method 'Java.Interop.JniRuntime.JniValueManager.<GetInvokerType>g__MakeGenericType|31_1(Type,Type[])'
	  does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.

`Expression.New()` requires the constructor be kept, so "fake it" by
wrapping `Type.GetType()` w/ `[DynamicallyAccessedMembers]`:

	src/Java.Interop/Java.Interop/JniValueMarshaler.cs(175): Trim analysis warning IL2072:
	  Java.Interop.JniValueMarshaler.CreateSelf(JniValueMarshalerContext,ParameterExpression):
	  'type' argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in call to 'System.Linq.Expressions.Expression.New(Type)'.
	  The return value of method 'System.Object.GetType()' does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.

`[DynamicallyAccessedMembers]` should be on properties, not getters:

	src/Java.Interop/Java.Interop/JniValueMarshalerAttribute.cs(33): Trim analysis warning IL2078:
	  Java.Interop.JniValueMarshalerAttribute.MarshalerType.get:
	  'Java.Interop.JniValueMarshalerAttribute.MarshalerType.get' method return value does not satisfy
	  'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor', 'DynamicallyAccessedMemberTypes.Interfaces' requirements.
	  The field 'Java.Interop.JniValueMarshalerAttribute.<MarshalerType>k__BackingField' does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.

Silence use of `Assembly.Location`, when it's optional:

	src/Java.Runtime.Environment/Java.Interop/JreRuntime.cs(106): warning IL3000:
	  Java.Interop.JreRuntime.CreateJreVM(JreRuntimeOptions):
	  'System.Reflection.Assembly.Location.get' always returns an empty string for assemblies embedded in a single-file app.
	  If the path to the app directory is needed, consider calling 'System.AppContext.BaseDirectory'.
	src/Java.Runtime.Environment/Java.Interop/JreRuntime.cs(323): warning IL3000: Java.Interop.JreNativeMethods..cctor():
	  'System.Reflection.Assembly.Location.get' always returns an empty string for assemblies embedded in a single-file app.
	  If the path to the app directory is needed, consider calling 'System.AppContext.BaseDirectory'.


~~ Future Work ~~

Make `JniRuntime.UseMarshalMemberBuilder` public for .NET 9, and
remove the `InternalsVisibleTo` from `Java.Interop.dll` to
`Java.Runtime.Environment.dll`.

`generator` should be updated to apply
`UnmanagedFunctionPointerAttribute` onto all `_JniMarshal_*` delegate
type declarations (56955d9a).


[4]: https://learn.microsoft.com/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute?view=net-8.0
[5]: https://learn.microsoft.com/dotnet/core/deploying/native-aot
[6]: https://learn.microsoft.com/dotnet/api/system.runtime.interopservices.unmanagedfunctionpointerattribute?view=net-8.0