How is your project different from IKVM?

[GeorgeS2019]

https://github.com/DjArt/IKVM.AWT.WinForms
https://medium.com/@mario.mastrodicasa/wpf-winforms-and-awt-swing-side-by-side-c2d11823e0a1

[masesdevelopers]

@GeorgeS2019 we don't know a lot of about https://github.com/DjArt/IKVM.AWT.WinForms, however seems it is based on https://github.com/ikvmnet/ikvm. IKVM, and maybe IKVM.AWT.WinForms, are a completely different approach to JVM-CLR interoperability:

• IKVM reports that it is:

  1. A Java virtual machine (JVM) implemented in .NET
  2. A .NET implementation of the Java class libraries
  3. A tool that translates Java bytecode (JAR files) to .NET IL (DLL or EXE files).
  4. Tools that enable Java and .NET interoperability
  5. A full JRE/JDK 8 runtime image.

• JNet instead:

  1. uses the chosen (see next point 5) Java virtual machine (JVM) directly from .NET, does not re-implement anything
  2. do not re-implement any class (at least adds someone, with specific JAR, for support): it creates wrappers around JVM classes which directly uses the one available within the JVM
  3. there is no translation between languages: JAR are used within the JVM, assemblies are used within .NET
  4. enable JVM and .NET interoperability using a .NET process, while JCOReflector enable JVM and .NET interoperability using a JVM (Java, scala, Kotlin, and so on) process
  5. generates the .NET classes which wraps the JVM API starting from a JDK 11, then can use, at runtime, any JRE/JDK between 11 to the latest one: to clarify, the build workflow executes the tests using the same .NET binaries, compiled in a common step, across Linux/Windows, different JDK vendors and different JDK versions

To summarize, with JNet:

• you are free to use your preferred combination of .NET version and JRE/JDK version/vendor at runtime, while IKVM rewrites a JVM 8 i.e. the ABI
• any assembly/project based on JNet is deployed without any binary linkage to a specific JDK/JRE: the JDK/JRE is not a constraint
• about graphics, looking in the code seems that IKVM.AWT.WinForms rewrites many classes and seems there is an image transfer from JVM/AWT to WinForms; instead JNet executes WinForms (WPF too) and AWT (Swing too) within the same process (in-proc): the MainUI threads are insulated (each graphics engine runs alone within the same process) and the graphic composition is done at OS level (Window Composition)
  • in a .NET process, with JNet, an user can start, and interact with, the in-proc AWT/Swing graphic both from a .NET console application and/or integrates AWT/Swing graphics within a WPF/WinForms application
  • in a JVM process, with JCOReflector, an user can start, and interact with, the in-proc WPF/WinForms graphic from a JVM console application and/or integrates WPF/WinForms graphic within an AWT/Swing application
  • Interaction between .NET and JVM (WPF/WinForms and AWT/Swing) happens invoking the methods available in the counterpart or by using callback listeners

Moreover, JNet can be used within PowerShell using the published JNetPS module.

JNet is a glue between .NET (non graphic code, WinForms, WPF) and JVM (non graphic code, AWT, Swing): evolutions and bug fixing of any component managed from the respectively owner are immediately available.