.NET Core has been around for almost three years. Why did we wait this long to support it in JNBridgePro? We’ve had several reasons.

The first release of .NET Framework was quite complete in terms of what its APIs covered. In contrast, .NET Core’s earliest releases were quite minimal. .NET Core 1.x lacked the Reflection.Emit APIs necessary for both generation of proxy DLLs and for runtime generation of dynamic proxies. While .NET Core 2.x added the Reflection.Emit APIs, there still remains a problem with the generation of proxy DLLs, forcing us to still use the .NET Framework’s proxy tools. In addition, .NET Core has always lacked the APIs for .NET Remoting, which JNBridgePro uses to implement the various communications mechanisms that connect the .NET and Java sides. When Reflection.Emit was also missing, it did not make sense to expend the effort to reimplement cross-platform communications without .NET Remoting, but once Reflection.Emit was available, it made sense to take the time to work around the other missing APIs.

In addition to missing APIs, the early versions of .NET Core were narrowly focused on server applications in general, and ASP.NET Core applications in particular. While we have always supported applications that run on servers and that use ASP.NET, many of our customers use JNBridgePro to develop desktop applications, and we hoped to support the same range of applications on .NET Core that we had always supported on .NET Framework. Part of .NET Core 3.0’s focus is to add support for desktop applications, which means that the range of applications that we can support on .NET Framework and .NET Core are now comparable.

Finally, Microsoft has publicly suggested that new .NET development projects should use .NET Core 3.0 rather than .NET Framework, due to .NET Core 3.0’s completeness and the fact that it runs equally well on Windows, Linux, and MacOS. Clearly, in order for any Java/.NET interoperability tool to remain relevant into the future, it’ll have to support .NET Core starting with 3.0 – it’s a no-brainer.

We’ll be supporting .NET Core as it evolves, as well as adding new features in upcoming releases. Some things you should expect to see: MacOS support, .NET Core-based generation of proxy DLLs, and UI embedding (on Windows at least).

See more about our support for .NET Core.

As always, do let us know if you have any questions, comments, or suggestions for new features.