Saxon .NET 10.x release based on https://www.nuget.org/packages/IKVM/8.2.1 instead of the currently used 8.1.5717.0
Today I have explored various ways to get Norm's Invisible XML tools CoffeeSacks, CoffeeGrinder and CoffeeFilter cross-compiled to .NET to be able to use them from Saxon .NET 10.x in .NET framework apps.
That failed in various ways, it seems Norm's code uses a method
java.lang.String.codePoints that is in current Java 8/1.8 releases but somehow documented only to have been introduced in Java 9/1.9; as the original IKVM is based on some rather old Java 1.8 OpenJDK it doesn't seem to know that method so an attempt to cross compile with that IKVM gives various errors like
IKVM.NET Compiler version 8.1.5717.0 Copyright (C) 2002-2015 Jeroen Frijters http://www.ikvm.net/ warning IKVMC0117: Emitted java.lang.NoSuchMethodError in "org.nineml.coffeegrinder.gll.GllParser.parse(Ljava.lang.String;)Lorg.nineml.coffeegrinder.gll.GllResult;" ("java.lang.String.codePoints()Ljava.util.stream.IntStream;")
While there seems to have been an attempt to fix this https://sourceforge.net/p/ikvm/mailman/message/35351681/ this doesn't seem to be in the IKVM version Saxonica uses to compile Saxon 10 for .NET.
Therefore I have looked at some of the existing IKVM forks and have successfully tested that I can compile Saxon 10.6 HE Java plus those three libraries from Norm with https://www.nuget.org/packages/IKVM/8.2.1 to get a .NET framework executable that run the Saxon 10 command line to register Norm's extension library for Saxon Java cross-compiled to .NET:
.\saxon106.exe -it -xsl:..\xslt\blog-xslt-3-by-example\invisible-xml\coffeepot-in-xslt-test1.xsl -init:org.nineml.coffeesacks.RegisterCoffeeSacks !indent=1 <?xml version="1.0" encoding="UTF-8"?> <doc> <date> <day>15</day> <month>February</month> <year>2022</year> </date> </doc>
Based on some Slack exchange with Norm I file this bug/feature request to consider whether a future 10.x .NET release can be based on that https://www.nuget.org/packages/IKVM/8.2.1 (or newer if they update), to allow the easy integration Invisible XML in XSLT and XQuery and XPath for the .NET framework by cross compiling Norm's Coffee* tools for .NET with the named IKVM.
My setup for that IKVM was e.g.
PS C:\Users\marti> .\ikvm\ikvm-revived821\ikvm\ikvmc.exe -target:exe -out:saxon106.exe 'C:\Program Files\Saxonica\SaxonHE10-6J\saxon-he-10.6.jar' 'C:\Users\marti\OneDrive\Documents\coffeesacks\coffeesacks-1.99.12\CoffeeSacks-1.99.12.jar' 'C:\Users\marti\OneDrive\Documents\coffeefilter\coffeefilter-1.99.9\CoffeeFilter-1.99.9.jar' 'C:\Users\marti\OneDrive\Documents\coffeegrinder\coffeegrinder-1.99.8\CoffeeGrinder-1.99.8.jar' IKVM.NET Compiler (8.2.1+Branch.main.Sha.e85684966cf595d7942d6930fda9c27d23b509e1) Copyright © 2022 Jeroen Frijters, Windward Studios, Jerome Haltom, Shad Storhaug note IKVMC0004: Using main class "net.sf.saxon.Transform" based on jar manifest warning IKVMC0100: Class "jline.console.completer.FileNameCompleter" not found warning IKVMC0100: Class "jline.console.completer.StringsCompleter" not found warning IKVMC0100: Class "org.apache.xml.resolver.helpers.Debug" not found warning IKVMC0100: Class "jline.console.ConsoleReader" not found warning IKVMC0100: Class "org.apache.xml.resolver.CatalogManager" not found warning IKVMC0100: Class "org.slf4j.LoggerFactory" not found warning IKVMC0100: Class "org.slf4j.Logger" not found
To run the executable I needed to copy various dlls like IKVM.Java.dll, IKVM.Reflection.dll, IKVM.Runtime.dll, System.Buffers.dll, System.Memory.dll,System.Numerics.Vectors.dll, System.Runtime.CompilerServices.Unsafe.dll to the same directory as the executable.
I have not identified whether all of them are needed.
A bit unsurprisingly no IKVM.OpenJDK.* dlls are directly used, I am not sure so far whether they have been all incorporated in the other dlls or somehow the existing ones from the assembly cache are used.
Updated by Michael Kay 7 months ago
While it's good to see that the Windward development of IKVM has made a lot of progress since we last tried it out, we're maintaining Saxon 10.x for .NET Framework for maximum stability and I think that moving to a new version of IKVM produced by a different development team feels risky. There are bound to be internal changes and we've no idea what the impact is likely to be. If there were any bugs in areas like multi-threading it could take a long time for these to be discovered and resolved. The benefits outlined in this bug issue don't feel to me to be strong enough justification.
Updated by Martin Honnen 7 months ago
I understand that doing that change on the stability branch is probably not worth the risk, even if invisible XML would be nice to have and there is no way forward for Saxon under the .NET framework. Of course there is also no way forward for the .NET framework but I do think that the existing version remains important as a Windows development platform for years to come.
Updated by Michael Kay 30 days ago
- Status changed from New to Rejected
We have made a decision not to do this. Saxon 10.x is being managed for stability, and we think this is best served by using the existing IKVM release for as long as the Saxon 10 branch is maintained. Hopefully no further maintenance releases will be needed on the 10.x branch.
Please register to edit this issue