Saxon

We need to establish whether IKVMC supports .NET Core and if not, whether there are any plans for it to do so.

Michael,

Are you actively investigating if IKVMC supports .NET Core and if not, is the investigation on the road map?

FYI, Microsoft announced .NET 5 a while ago, promising:

• Multiple runtime support (.NET Core, Mono)
• Java interoperability, based on Mono's fork of IKVM

It seems Microsoft has provided a preview of .NET 5 in March 2020 but unfortunately the plans to support Java compatibility seem to have been axed: https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-1/#comment-4932:

... when we will start to see the Java interoperability features for .NET 5? ... We had to scope that out of the .NET 5.0 release in order to build everything else

Thanks, yes, I saw that too. I have raised an enquiry with Microsoft, so far without response.

There is an alternative route to reach the target auditory. This way Language Services API now is used to integrate to plug languages into IDEs, or how Google Chrome splits rendering engine from script engine and from browsing context.

So, basic idea is to create surface API that will start separate process where Saxon runs, and where real work is done. That process may die when idle.

Communication can be done in a number of ways: sockets, pipes, shared memory, memory mapped files, REST.

As an ultimate solution it's possible to create a server (service) that always runs and is ready to accept requests. This close to database and web servers.

The advantage of such concept could be:

• a better separation, which might be good for stability and security;
• speed, as running service may accept repeated request faster, without JVM startup impact;
• speed, as service may collect analytics, and cache data structures to serve better;
• single main code base for the product, and thin communication API per host language.

things are encouraging, see https://github.com/ikvm-revived/ikvm/issues/20 it seems that ikvm is being running on .net standard 2.0 / 2.1

If I understand https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-1/#comment-8433 correctly than .NET 6 will not provide any Java interop either, although already planned for .NET 5 but later cut.

Thanks. We're currently working on an approach for future .NET versions that isn't dependent on anything coming out of Microsoft, or on developments to IKVM, nor on run-time JVM interop solutions: specifically, we're working on source-to-source Java to C# conversion. Will report on progress when we're a bit further down the road, but we've convinced ourselves that it's feasible.

That's really great to hear because we are transitioning to .net core and at the same time we will use xsl-fo, so we need saxon. Are you developing the source to source compiler in a private repo or open-source ?

The transpiler code is being developed on the assumption that it's for our own use only -- I'm following the maxim from Fred Brooks' mythical man month that writing a program that does exactly what you need and is intended only for your own use is one tenth the effort of writing code that other people can use for different tasks.

I hope you made great progress, I desesperately need saxon for .net core. Do you have any date or timeline ?

Sylvain Pointeau wrote:

I hope you made great progress, I desesperately need saxon for .net core. Do you have any date or timeline?

No, sorry, we don't do that kind of planning because there are still far too many uncertainties to make any predictions realistic. Let's say some time in 2021, hopefully.

Does the release of Saxon 11.1 help resolve this?

Thanks Michael

.Net Core is becoming the deployment environment of choice in the organisation I am working with and so this is a great step forward, well done.