If you’ve spent any time playing with the new JNBridgePro 10.0 and its support for .NET Core 3.0 and for .NET Framework, you’ll have noticed that they’re not exactly the same. While we’ve tried to make them as close as possible, there are differences, some of which are unavoidable, and some of which are the result of design decisions on our part. Here’s a discussion of some of the differences, and why they’re there.

Configuration: When used with the .NET Framework, applications using JNBridgePro make use of .NET’s app.config XML file for configuring JNBridgePro-specific aspects of the application, such as whether shared memory, TCP/binary, or HTTP/SOAP communications are being used. .NET Core uses a different configuration model, however. While XML is still an option, .NET Core encourages the use of JSON for configuration files, so we decided to support that when using .NET Core. In addition, there is more flexibility in .NET Core’s configuration mechanism, so we decided to include configuration information in a JNBridgePro-specific JSON file jnbridgeConfig.json that is placed in the folder with the application and jnbshare.dll. The structure of the JSON file is similar to the structure of XML-based JNBridgePro configuration in the .NET Framework-targeted JNBridgePro, so the JSON configuration files should look familiar.

In both .NET Framework and .NET Core, you can still configure JNBridgePro programmatically with our configuration API.

Proxy generation: For .NET Framework, JNBridgePro offers both GUI-based and command-line based standalone proxy generation tools, as well as plugins for Visual Studio and Eclipse. For .NET Core, JNBridgePro only offers a command-line standalone tool. This is because of .NET Core’s incomplete support for windowing. Yes, .NET Core 3.0 supports Windows Forms and Windows Presentation Foundation (WPF), but only on Windows. Since our goal is to provide identical support for .NET Core on all platforms that .NET Core supports (Windows, Linux, and soon MacOS), and since .NET Core and its tooling are much more command-line-centric than .NET Framework and its tooling, we decided to offer the proxy tool in command-line form.

The .NET Core-targeted proxy generation tool also only generates Java-side proxies for Java-to-.NET projects. For .NET-to-Java projects, you must use the .NET Framework-targeted proxy generation tool (GUI-based, command-line, or Visual Studio plugin) to generate .NET-side proxies. This is because the proxy generation tool creates the proxies inside a memory-resident assembly, then writes the assembly out to a DLL file. The problem is that .NET Core lacks the API to write the memory-resident assembly out to a file. While there is at least one open-source package that supports this capability, we had trouble getting this to work in a timely fashion. Rather than delay the release of .NET Core-to-Java support, we require you to generate the proxies using the .NET Framework-targeted proxy tools. The generated proxy DLLs work just fine in .NET Core projects. Because you have to use a .NET Framework-targeted proxy tool, this means that proxy generation must take place on a Windows machine with .NET Framework installed (which means just about any modern Windows machine.) We realize that this is an inconvenience, and we hope to rectify it in an upcoming release.

UI embedding: As .NET Core only supports Windows Forms and WPF on Windows, and supports no other windowing mechanism, we’ve decided to leave out support for UI embedding in .NET Core-targeted JNBridgePro.

Plugins: UI embedding isn’t supported in .NET Core-targeted JNBridgePro. As the Eclipse plugin makes use of UI embedding, we’re not providing a .NET Core-targeted Eclipse plugin. Similarly, as we can’t currently generate .NET-side proxy DLLs with a .NET Core-targeted proxy tool, it didn’t make sense to provide a .NET Core-targeted Visual Studio plugin. However, this could change in a future release.

Licensing: .NET Framework-targeted JNBridgePro makes use of the registry to help find license files when they’re in the JNBridgePro installation folder. Since .NET Core can run on OS platforms that don’t support the registry, the .NET Core-targeted version requires that the license file be in the executable’s folder or that the configuration file contain a path that points to the license file’s folder.

In addition, since .NET Core only supports Windows Forms on Windows, the .NET Core version of the registration tool is command-line only.

HTTP/SOAP communications: While we could have implemented the HTTP/SOAP communications mechanism in .NET Core, we decided not to since it seems to be a little used feature. We will revisit this decision if there is significant user demand for this mechanism. TCP/binary and shared memory communications are both supported on .NET Core.

Failover mechanism: The JNBridgePro failover mechanism, which allows users to specify an alternate Java side to be contacted by the .NET side in case the primary one fails, is not supported when using .NET Core because a crucial API that is required to implement this mechanism is not available in .NET Core. However, this is a little-used feature and, in any case, we recommend that users employ native failover mechanisms offered by targeted .NET and Java applications, so eliminating this feature should not present a hardship.

Organization of components: The JNBridgePro components provided to run on .NET Core resemble those used for .NET Framework, but there are a few differences. First, we have decided to provide our applications as framework-dependent deployments (FDDs). (See https://docs.microsoft.com/en-us/dotnet/core/deploying/.) This means that the proxy tool, registration tool, and .NET side server are all DLLs, not EXEs, and should be invoked using the ‘dotnet’ command (e.g., ‘dotnet jnbproxy.dll’.) This allows the same file to be run on all .NET Core-supported OS platforms. With self-contained deployments (SCDs), the .NET Core platform is packaged with the application, which means that different deployments must be created for Windows, Linux, and MacOS.

The components required for shared memory are slightly different in .NET Core. While jnbsharedmem_x64/x64.dll and jnbjavaentry_x64/x86.dll are also part of the .NET Core-targeted components (although they are different files from the ones for .NET Framework and are not interchangeable with the .NET Core-targeted components), there is only a single version of jnbjavaentry2.dll, since it is now an entirely managed DLL and will work regardless of bitness and underlying OS.

For Linux, the .NET Core-targeted native shared memory components have names that conform to Linux conventions: libJNBSharedMem_x64.so and libJNBJavaEntry_x64.so. Note that only 64-bit Linux is supported. If the Windows-native and Linux-native components are both included in a deployment, the correct component will be loaded based on the underlying OS.

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.