[java-interop] Resuscitate Mono GC Bridge

[jonpryor]

Context: dotnet/runtime#112109
Context: f5ce0ad
Context: 3824b97

Commit f5ce0ad copied portions of the .NET for Android Mono GC Bridge
code into src/java-interop, but to build that code "on Desktop" --
for possible CI and unit test use -- it needed to build against Mono
somehow.

The actual "how" was unspecified:

• The macOS build implicitly required that
  /Library/Frameworks/Mono.framework exist, and would pull in
  header files and libraries from there.

• Linux and Windows were not support at all.

Eventually src/java-interop got Windows build support in 3824b97.
This allowed Java.Interop-Tests.dll to run under .NET Core, but
this did not contain any GC bridge code; it was just the JNI
wrapper functions such as java_interop_jnienv_get_version() and
JVM loading functions such as java_interop_jvm_create().

Eventually the Mono GC bridge code effectively bitrotted, as nothing
built it anymore. .NET for Android has its own (original!) copy,
and CI is primarily concerned about .NET (Core) and not Mono.

Three things have happened in the meantime:

1. The Mono team was absorbed into the .NET team, with the new
   "MonoVM" as a supported backend for .NET.
   MonoVM is used by .NET for Android and a supported backend with
   .NET for iOS, Mac, etc.

2. MonoVM is now provided as NuGet packages!

3. There are now efforts to investigate adding something like the GC
   Bridge to CoreCLR and NativeAOT; see GC: Support object level interop on Android runtime#112109.
   Some developers involved with this would like to debug how the
   current GC bridge works. On desktop Windows.

Embrace the new world order: remove support for using "system" Mono
installations, the _CreateMonoInfoProps target, generation of
MonoInfo.props, etc., and instead use MonoVM packages to provide
the MonoVM runtime and header files needed for compilation & linking.
This allows for a consistent build environment across Linux, macOS,
and Windows, though Windows adds one wrinkle:

MonoVM doesn't contain a coreclr.lib file for linking.

Add coreclr.def and a coreclr.lib file to use for linking against
MonoVM on Windows. coreclr.lib was created by:

lib /def:coreclr.def /out:coreclr.lib /machine:X64

where coreclr.def contains the mono_ symbols that were referenced
by the macOS libjava-interop.dylib build, as per
nm bin/Release-net8.0/libjava-interop.dylib | grep 'U _mono'.

Update src/java-interop so that it builds with the latest MonoVM
headers (<mono/metadata/appdomain.h> must now be included), and
allow it to build under Windows (use Interlocked* instead of
clang's __sync_*_and_fetch().)

There is one ("tiny") problem with this approach: .NET 9 doesn't
contain MonoVM packages. For example, the
Microsoft.NETCore.App.Runtime.Mono.osx-x64 NuGet package was
last updated for .NET 9 Preview 7; the last stable version is for
.NET 8.

Fortunately we only recently migrated to .NET 9 (f30e420).
Update JniRuntime.cs so that we can build the repo when overriding
with -p:DotNetTargetFramework=net8.0.

Update Java.Interop.Sdk so that the .jar it creates is
appropriately copied to $(OutputPath) of the referencing project.
This required using %(Content.CopyToOutputDirectory)=PreserveNewest
alongside using %(Content.TargetPath) -- which sets the relative
name within $(OutputPath) -- and in turn required making
_JavaCreateJcws run after CoreCompile instead of Build, so that
it would properly participate in %(CopyToOutputDirectory) logic.

The code to detect that MonoVM is being used has changed; the
Mono.Runtime type no longer exists. Mono.RuntimeStructs needs
to be checked for instead.

Update TestJVM.GetJvmLibraryPath() so that it can find
bin\BuildRelease\JdkInfo.props when running an app from the
samples directory and not from bin\TestRelease*\….

All of this allows for samples/Hello-Java.Base to be built against
and run with MonoVM, on Windows!

# need Release config build because `dotnet publish` is implicitly Release
dotnet build -c Release -t:Prepare -p:DotNetTargetFramework=net8.0 Java.Interop.sln
dotnet build -c Release -p:DotNetTargetFramework=net8.0 Java.Interop.sln

# -p:UseMonoRuntime enables use of MonoVM
dotnet publish --self-contained -p:UseMonoRuntime=true -p:DotNetTargetFramework=net8.0 -p:UseAppHost=true -p:ErrorOnDuplicatePublishOutputFiles=false samples/Hello-Java.Base/Hello-Java.Base.csproj -r win-x64

Note: replace -r win-x64 with the appropriate RID for your host.

With that setup, you can then run the sample:

> samples\Hello-Java.Base\bin\Release\win-x64\publish\Hello-Java.Base.exe
MonoVM support enabled
# jonp: LoadJvmLibrary(C:\Users\jopryo\android-toolchain\jdk-17\bin\server\jvm.dll)=140710450692096
# jonp: JNI_CreateJavaVM=140710454831248; JNI_GetCreatedJavaVMs=140710454831280
# jonp: executing JNI_CreateJavaVM=7ff9b4ad2890
# jonp: r=0 javavm=7ff9b51fd7f0 jnienv=24d781dddc0
WARNING in native method: JNI call made without checking exceptions when required to from CallStaticObjectMethodV
binding? net.dot.jni.sample.MyJLO@a09ee92

[jonpryor]

Draft commit message:

Context: https://github.com/dotnet/runtime/issues/112109
Context: f5ce0ad22b3adb6ccdd5f8587eab310d415e1f16
Context: 3824b974dada6f302ed5f7b7f97ffbd08990a82a

Commit f5ce0ad2 copied portions of the .NET for Android Mono GC Bridge
code into `src/java-interop`, but to *build* that code "on Desktop" --
for possible CI and  unit test use -- it needed to build against Mono
*somehow*.

The *actual* "how" was unspecified:

  * The macOS build implicitly required that
    `/Library/Frameworks/Mono.framework` exist, and would pull in
    header files and libraries from there.

  * Linux and Windows were not support *at all*.

Eventually `src/java-interop` got Windows build support in 3824b974.
This allowed `Java.Interop-Tests.dll` to run under .NET Core, but
this did *not* contain any GC bridge code; it was *just* the JNI
wrapper functions such as `java_interop_jnienv_get_version()` and
JVM loading functions such as `java_interop_jvm_create()`.

Eventually the Mono GC bridge code effectively bitrotted, as nothing
*built* it anymore.  .NET for Android has its own (original!) copy,
and CI is primarily concerned about .NET (Core) and not Mono.

Three things have happened in the meantime:

 1. The Mono team was absorbed into the .NET team, with the new
    "MonoVM" as a supported backend for .NET.
    MonoVM is used by .NET for Android and a supported backend with
    .NET for iOS, Mac, etc.

 2. MonoVM is now provided as NuGet packages!

 3. There are now efforts to investigate adding something like the GC
    Bridge to CoreCLR and NativeAOT; see dotnet/runtime#112109.
    Some developers involved with this would like to debug how the
    current GC bridge works.  *On desktop Windows*.

Embrace the new world order: remove support for using "system" Mono
installations, the `_CreateMonoInfoProps` target, generation of
`MonoInfo.props`, etc., and instead use MonoVM packages to provide
the MonoVM runtime and header files needed for compilation & linking.
This allows for a consistent build environment across Linux, macOS,
and Windows, though Windows adds one wrinkle:

MonoVM doesn't contain a `coreclr.lib` file for linking.

Add `coreclr.def` and a `coreclr.lib` file to use for linking against
MonoVM on Windows.  `coreclr.lib` was created by:

	lib /def:coreclr.def /out:coreclr.lib /machine:X64

where `coreclr.def` contains the `mono_` symbols that were referenced
by the macOS `libjava-interop.dylib` build, as per
`nm bin/Release-net8.0/libjava-interop.dylib | grep 'U _mono'`.

Update `src/java-interop` so that it builds with the latest MonoVM
headers (`<mono/metadata/appdomain.h>` must now be included), and
allow it to build under Windows (use `Interlocked*` instead of
clang's `__sync_*_and_fetch()`.)

There is one ("tiny") problem with this approach: .NET 9 doesn't
contain MonoVM packages.  For example, the
[`Microsoft.NETCore.App.Runtime.Mono.osx-x64` NuGet package][0] was
last updated for .NET 9 Preview 7; the last *stable* version is for
.NET *8*.

Fortunately we only recently migrated to .NET 9 (f30e420a).
Update `JniRuntime.cs` so that we can build the repo when overriding
with `-p:DotNetTargetFramework=net8.0`.

Update `Java.Interop.Sdk` so that the `.jar` it creates is
appropriately copied to `$(OutputPath)` of the referencing project.
This required using `%(Content.CopyToOutputDirectory)`=PreserveNewest
alongside  using `%(Content.TargetPath)` -- which sets the relative
name within `$(OutputPath)` -- and in turn required making
`_JavaCreateJcws` run after `CoreCompile` instead of `Build`, so that
it would properly participate in `%(CopyToOutputDirectory)` logic.

The code to detect that MonoVM is being used has changed; the
`Mono.Runtime` type no longer exists.  `Mono.RuntimeStructs` needs
to be checked for instead.

Update `TestJVM.GetJvmLibraryPath()` so that it can find
`bin\BuildRelease\JdkInfo.props` when running an app from the
`samples` directory and not from `bin\TestRelease*\…`.

All of this allows for `samples/Hello-Java.Base` to be built against
and run with MonoVM, on Windows!

	# need Release config build because `dotnet publish` is implicitly Release
	dotnet build -c Release -t:Prepare -p:DotNetTargetFramework=net8.0 Java.Interop.sln
	dotnet build -c Release -p:DotNetTargetFramework=net8.0 Java.Interop.sln

	# -p:UseMonoRuntime enables use of MonoVM
	dotnet publish --self-contained -p:UseMonoRuntime=true -p:DotNetTargetFramework=net8.0 -p:UseAppHost=true -p:ErrorOnDuplicatePublishOutputFiles=false samples/Hello-Java.Base/Hello-Java.Base.csproj -r win-x64

Note: replace `-r win-x64` with the appropriate RID for your host.

With that setup, you can then run the sample:
	
	> samples\Hello-Java.Base\bin\Release\win-x64\publish\Hello-Java.Base.exe
	MonoVM support enabled
	# jonp: LoadJvmLibrary(C:\Users\jopryo\android-toolchain\jdk-17\bin\server\jvm.dll)=140710450692096
	# jonp: JNI_CreateJavaVM=140710454831248; JNI_GetCreatedJavaVMs=140710454831280
	# jonp: executing JNI_CreateJavaVM=7ff9b4ad2890
	# jonp: r=0 javavm=7ff9b51fd7f0 jnienv=24d781dddc0
	WARNING in native method: JNI call made without checking exceptions when required to from CallStaticObjectMethodV
	binding? net.dot.jni.sample.MyJLO@a09ee92

[0]: https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.Mono.osx-x64/

[Copilot]

PR Overview

This PR updates the Java interop code to resuscitate the Mono GC Bridge by switching from relying on system Mono installations to using MonoVM NuGet packages. Key changes include:

• Adding optional logging support for JVM path probing in tests.
• Updating the Mono detection mechanism and logging in the runtime.
• Adjusting build and runtime behavior for better cross-platform compatibility.

Reviewed Changes

File	Description
tests/TestJVM/TestJVM.cs	Added logger parameters to several methods, and introduced a new probing strategy for JdkInfo.props.
samples/Hello-Java.Base/Program.cs	Updated JVM path handling and added console logger creation based on verbosity.
src/Java.Runtime.Environment/Java.Interop/JreRuntime.cs	Changed Mono detection from "Mono.Runtime" to "Mono.RuntimeStructs" and logged MonoVM support.
src/Java.Interop/Java.Interop/JniRuntime.cs	Wrapped a break call with a NET9_0_OR_GREATER conditional compilation directive.

Copilot reviewed 15 out of 15 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

tests/TestJVM/TestJVM.cs:121

• Accessing jdkJvmPath.Value without a null-check can lead to a NullReferenceException if the XML element is missing. Consider verifying that jdkJvmPath is not null before using its Value.

logger?.Invoke (TraceLevel.Verbose, $"TestJVM: $(JavaSdkDirectory)={jdkPath?.Value}; $(JdkJvmPath)={jdkJvmPath.Value}");

[jonathanpeppers]

Is it worth making it error on linux? Or can we guess what the paths might be there?

[jonpryor]

These are values provided to the Cmake CMAKE_OSX_ARCHITECTURES variable. $(CmakeOsxArch) is not used for Linux, and would make no sense there.

[jonathanpeppers]

There are two sections in this file for: $([MSBuild]::IsOSPlatform ('osx')) and $([MSBuild]::IsOSPlatform ('windows')), so it just made me think the linux one is missing.

[jonpryor]

Fair, but currently I don't think anything is missing for Linux.

(Note: I haven't actually built Linux yet, so Linux is basically a thought experiment until someone does so. 😉)

[jonathanpeppers]

Are the other files inputs like coreclr.def, coreclr.lib?

[jonpryor]

I do not understand the question.

Conceptually, coreclr.lib could be added as an input, but (1) it should rarely change, and (2) if it does need to change, it's because you have a build failure anyway, e.g. because we added a call to a new mono_whatever() function that wasn't previously listed in coreclr.def/coreclr.lib.

It feels moot to add them, unless we add a Target which generates coreclr.lib from coreclr.def…

[jonathanpeppers]

I guess the question is if coreclr.def/coreclr.lib change, do you want cmake to run?

[jonpryor]

If they change, it's because cmake errored out, in which case the Outputs won't exist, in which case updating coreclr.* won't matter, because re-building will re-run cmake anyway.

The only scenario this won't be the case is if you build successfully, then update the .lib to remove used symbols, and build again…

in which case, yeah, coreclr.lib should be an Input. Doh!