FWD » Core Development » Runtime Infrastructure

In #2148, we used iKVM to deliver a subset of our runtime in .NET CLR. This worked well but may not be a solution for the full runtime support. We use a range of quite advanced techniques including heavy use of reflection, byte code generation, dynamic proxies (including both the Java version and our own implementations), custom class loading, dependency injection (e.g. AspectJ) and more. These areas might not move over to .NET via iKVM.

As noted in #11540, we could implement automated transformation from Java to C#. That would have a huge advantage of allowing us to transform our runtime code (server, client etc...). Even if we chose a different approach to emit the converted code as C#, we still may want to implement the full transformation pipeline so that we can convert our Java runtime code to C#. I would still expect that some portions of the runtime code would have a native C# implementation (see the advanced techniques above). This would not be a one time conversion, but would be run whenever we make changes on the Java side. I don't plan to fork our runtime. We will only maintain in one place, that is the Java runtime.

My expectation is that the bigger issue (and maybe most of the work for this task) will be to handle our 3rd party Java and JDK dependencies. Our code uses a wide range of existing Java code and much of it won't be available in .NET (we don't need these in C#, they can be implemented in any performant .NET language).

• If the dependency has a .NET version, then we need to ensure it is compatible and is at the same version.
• If a dependency does not have a .NET version or if it is not equivalent, then we will need to consider how we move away from that dependency.
  • Find a replacement that has equivalent support in both Java and .NET.
  • Write an abstraction/mapping layer (in the conversion) that allows the Java dependency to be mapped to or replaced by .NET code.
  • Write our own replacement that is implemented in both Java and .NET.

If a dependency is not needed at runtime in .NET, then we can ignore it. I see no reason to implement our development tools in C#, the only exception is the dynamic queries case which is a kind of runtime conversion.

iKVM looks like it supports only Java 8.

• reflection
• aspects
• bytecode generation (DMOs, TRPL expressions)
• JNI

We will need to port all these for FWD to run in .NET.

Good point about the JNI code. .NET has good native support that will directly replace libffi (or the Java FFM support if we move to that in #9684).

Constantin Asofiei wrote:

iKVM looks like it supports only Java 8.

This might be a problem as we have just switched to newer JDK.

Features which we use in FWD, beside 3rd party jars and JDK:

• reflection

I think the basic reflection is possible. java.lang.Class, at least, is accessible.

• aspects

I do not have currently a solution for this.

• bytecode generation (DMOs, TRPL expressions)

The ikvm actually converts dynamically the classes from jar to CIL at the start of the application. It might expose some APIs for doing that later, during runtime, allowing us to keep the code for generating Java classes and convert them on-the-fly. After all, the bytecode we generate is not really complicated.

• JNI

Also no solution here, yet. Maybe the mono has specialised API? Can this part be rewritten? It's not that large, but the cost is given by maintenance.

Further investigations should be done. The CLR/C# may offer some features that are not available in Java (I think Greg mentioned properties), we just need to figure out if they are of any help and how will make use of them.

Note that the ikvmc compiler will do the conversion of a .jar into a .ddl. That would be perfect (we would convert the p2j.jar when needed) but it is not enough. All dependency tree of jars will have to be converted that way. I expect the application.jar should pose less problems because the structure of the classes is pretty similar, with calls to FWD runtime.

I don't think the customer would accept iKVM as a solution. And I'm worried that the more advanced usage would not work well or would have problems that are impossible to address.

The association with Java 8 is especially concerning as we cannot stay on that platform. We should plan that we will be implementing our runtime support at a source level in .NET.

In regard to JNI, .NET has good support for loading libraries, searching for functions, making native API calls to those functions, allocating memory and so forth. It is just some work to implement the replacement.

Would the order of conversion be:
1. Customer application to Java, which establishes a baseline, then convert FWD to C# and compare the output to converted java and original 4gl
2. Java FWD to C# FWD, then convert the customer application directly to C# without a java conversion?
depending on the approach we could end up with failures and not know whether they come from the conversion of the client's application or the FWD port to C#.

The second item makes a lot of sense.

The good news is that AI can do 90% of the job because most of .NET elements shares the same pattern as Java, like JDBC vs ADO.NET, JNIs, etc.
The most challenging from my opinion to port is the Swing GUI and Jetty.

Artur Școlnic wrote:

Would the order of conversion be:
1. Customer application to Java, which establishes a baseline, then convert FWD to C# and compare the output to converted java and original 4gl
2. Java FWD to C# FWD, then convert the customer application directly to C# without a java conversion?
depending on the approach we could end up with failures and not know whether they come from the conversion of the client's application or the FWD port to C#.

The application conversion approach is being discussed in #11540. We will be testing both Java and C# versions of the same application to ensure that the runtimes are equivalent.

I agree that AI will help greatly with any .NET code that needs to be hand written BUT wherever possible we will convert our Java runtime code into C# using repeatable automation. I do not want to maintain 2 independent versions of our runtime, except for some minimized portions that must be different.

An interesting idea which has occurred, but it is not related to porting the FWD runtime to C#.

Blazor Hybrid, a framework from Microsoft has been released for a quite some time. It is the alternative for Electron apps, which is intended to build a web app and deliver as a native app for multiple platforms like Windows/mobile platforms.

The interesting fact is that this framework is not just a web view. It allows custom HTML elements, which are the placeholders for truly native components. So, alongside a full web app, you can also integrate the app with a Windows Forms or a OCX component easily.

The idea is that we can achieve almost full OCX compatibility (without rewriting the components in JS) by creating a new type of GUI driver, which works with Blazor Hybrid and integrate that component into our existing runtime. The only caveat is that this requires Windows on FWD server and on the user's system to run Blazor and OCX.
CLR overhead is not an issue because the .NET related code can be easily compiled into a native DLL using .NET AOT.