IKVM 8.9 changes

[wasabii]

Discussion to go over upcoming changes for IKVM 8.9.

The biggest change in this release will be the introduction of platform specific base libraries. That means we will now distribute 4 different versions of IKVM.Java:

a) Reference Assembly: the version of the assembly you should build code again, and to which ikvmc should link against. Right now this is a mirror of the Windows version of the assembly. This will change over time, as we gain the ability to produce actual reference assemblies: public APIs only, no method bodies, etc.
b) Windows
c) Linux
d) OSX

(b), (c) and (d) are different versions of IKVM.Java targeting their respective platforms. They will and do contain actual different code. Since IKVM's base library is largely a recompilation of OpenJDK, and OpenJDK has platform specific code and classes, we can now more easily use the OpenJDK code exactly as is for IKVM. There are different versions of different classes for different OSs.

And more importantly, the native C code that OpenJDK contains is organized along these boundaries. And since we now mirror those, we can make use of that native code. And we are.

8.9 will largely replace our IO layers, network, process launching, etc, with the raw OpenJDK versions. Directly compiled. This has allowed us to remove a huge amount of C# code out of IKVM. We no longer need our own implementation of NIO, for instance. We just use the classes OpenJDK ships, which differ by OS.

Support for a lot of things we didn't previously do has come along for the ride with this. For instance, the Kerberos stuff is now enabled. SCTP on Linux. We no longer have our own code paths for path canonicalization, reading from files, or memory mapped streams. This is all just using the distributed OpenJDK code. Integrating later versions of the JDK should now be way easier.

And, though it isn't merged in just yet, I plan to have AWT working in this release.

But this does make distribution a bit more complex. Since we now have three versions of IKVM.Java, when you build/publish your .NET app, you have to make sure it's set up right. The IKVM NuGet packages are set up to do this right: we use the runtime/{rid}/lib/* folder paths to distrbute the three versions of the library. And the reference assembly is in refs/. On output, then, if doing a RID-specific publish, MSBuild selections the right DLL to include. However, if doing a non-RID-specific build, you end up with a local runtimes/{rid}/win|linux|osx/lib directory. And .NET needs to locate the right DLL at runtime.

Which CoreCLR does. But Framework doesn't.

I thought through a lot of possible ways to get this working with Framework, but couldn't settle on anything that worked. As a consequence, we only distribute the IKVM.Java Windows copy for for .NET framework apps. This means out of the box IKVM really only works for Framework on Windows. And the build system won't properly generate Framework on Linux or OSX (Mono) output. But, well, our Mono support has been broken for quite awhile anyways, so at least today this isn't a change.

But for those of you not using the NuGet packages, but integrating the assemblies in some other way, this makes it harder for you. You've got to figure out how you want to include the correct IKVM.Java file for your build.

[GeorgeS2019]

I plan to have AWT working in this release

Thank you