8.7.0 Plan

[wasabii]

We have recently begun successfully building IKVM.Java and IKVM.Runtime for .NET 6. The current plan for 8.7 is to have .NET 6 releases of all of our various platforms. Additionally, because of the enabling of .NET 6, we are now capable of building OSX ARM64 versions of the tools.

However, there is an issue with the build system for the tools: it doesn't appear we can easily produce BOTH .NET 3.1 and .NET 6.0 builds of the tools and executables at the same time. Something with how RID restores work.

We have seperately considered, now that we have .NET 6 support, and .NET 3.1 is long off the supported list, that we drop support for .NET Core 3.1 tools. This issue will partially force that.

Additionally, now that we have the tools TFM independent, we should be able to use .NET 6 tools to generate assemblies against .NET Core 3.1 libraries.

So, all of this together, leads to this prediction for IKVM 8.7.0:

We will be introducing OSX-ARM64 tooling support.
We will be dropping .NET Core 3.1 versions of the tooling.
.NET Core 3.1 projects will continue to be buildable: using .NET 6 tooling.
We will be dropping the .NET Core 3.1 versions of the JRE and JDK images. This means no more java.exe, javac.exe, etc, distributed built for .NET Core 3.1. This is probably the only feature loss. But, usage of these is fairly minimal, restricted to projects that target .NET Core 3.1 and also require a full JRE/JDK.
IKVM.Runtime and IKVM.Java will continue to have .NET Core 3.1 versions, generated with the .NET 6 tooling. So, IKVM will continue to work on normal .NET Core 3.1 projects, with the exception about JRE/JDK images above.

It is likely that in 8.8 or above, we will drop .NET Core 3.1 completely.

[wasabii]

@AliveDevil Convinced me that we would be okay upping the .NET Framework minimum supported version to 4.7.2. This puts us back to Server 2008 R2 SP1, which should be adequate.

Also, I've decided that at final release time we'll just be dropping Core 3.1 completely. So, 8.7 will support NET472 and NET6.0.

[BiologyTools]

When will ikvm 8.7 be released? This would be awesome for the bioformats library.

[wasabii]

Longer than I thought. I got it all building and stuff, but then uncovered that the file locking operations on OS X were insufficient, which caused IKVM.Maven.Sdk to fail.

In order to fix that, I'm working on introducing more native lib support, specifically using libnio to replace the file locking support in IKVM.

And that has caused a large reorganization in how native libs are bundled.

[wasabii]

Just merged in the branch I was working on which should fix all the OS X bugs blocking IKVM.Maven.Sdk. Once that builds I'll do a prerelease.

[askids]

@wasabii what will be the specific java sub version that it will be based on? At our site, we typically get tagged for using outdated java versions. So just checking.

[AliveDevil]

u90.
I’m unfortunately not finished with the u152 update.

[wasabii]

https://github.com/ikvmnet/ikvm/releases/tag/8.7.0-pre.1

Building now. Preparing a similar IKVM.Maven release.

[wasabii]

So the main thing I've been trying to deal with for the last week or so is the interaction of the new OpenJDK C libraries, and AppDomains on Framework. They break each other. The way native JNI stuff tends to work is that they have an initialization method, which uses the JNIEnv to retrieve the fieldIDs, methodIDs, jclass instances, etc, of various Java-side things, and cache them into static data structures of the JNI library.

The problem here is that if they fetch the methodID for a given Java method, when invoked inside one AppDomain, then then IKVM ends up running inside a second appdomain, calling the same JNI library, that library will have a methodID originating from the IKVM running in the first AppDomain. Obviously this cannot work.

It's not a new problem, apparently. This would break any existing Java application using JNI and caching things. The new problem is because we're now starting to use a lot of OpenJDK C code, the BCL itself breaks.

It would be cool if we could load a separate copy of the JNI native library per-AppDomain. But, this isn't possible on Windows and OSX anyways. It can technically be accomplished on Linux using dlmopen. But, not an option.

It would be cool if we could transpile the OpenJDK C to MSIL and just load it into the AppDomain. Super cool. But that would require being able to do that.

So, no solution here.

Except to declare we no longer support AppDomains. Which, after a lot of thought, I'm okay with. Yes, we're breaking IKVM from being used inside of a feature that is an offical part of Framework. But, it's nothing that can't possibly be worked around: because anybody moving to Core would have to abandon AppDomains for their design anyways. So, I'm okay with this. The trade off from being able to consume the OpenJDK C code is huge. It's allowed me to get most of the OSX stuff working. And abandon reems of custom maintained C#. All to support a feature that can only be used on Framework? Naw.

So that's my direction on this.

[wasabii]

https://github.com/ikvmnet/ikvm/releases/tag/8.7.0-pre.1

Is being built now. Will take a couple hours.

Same code as 8.7.0-dev.531 published on internal NuGet, which is available to try now.

[martin-honnen]

Great news. Will be tough today with I think during the afternoon Microsoft doing Windows patch day and releasing .NET 8 release candidate 2 to be able to really explore it in depth but I am sure I will do that during the week.

[martin-honnen]

Using https://www.nuget.org/packages/IKVM/8.7.0-pre.1 and https://www.nuget.org/packages/IKVM.Maven.Sdk/1.6.0-pre.1 I managed to build and run some .NET 6 project using Saxon HE 11.6 from Maven under MacOS 13 and arm64.
That is a great accomplishment by you and anyone working on IKVM and IKVM.Maven.
Congrats for that and many thanks, looks like I can finally build cross platform .NET apps on an arm64 Mac M1.

[wasabii]

@BiologyTools You're up!