Calling Java code from a C# COM DLL that’s used by a WIN32 application?

Question

I have a very simple problem. I have an application which is written in Delphi 2007 for WIN32. It uses a C# DLL which is imported into the project through it's COM interface and a simple trick to avoid registering the COM object. But now I have a Java-generated .JAR file that I want to call from my application. And while I have access to the Delphi and the C# code, I just don't have access to the Java code.

I can do two things. Either I call the Java class from the Delphi code, which would then be called from the C# code which is called again from the Delphi code. Or I just call the Java code directly from C#. (Which is called from Delphi again.)

I know this is a complex setup. The Delphi application contains a GUI and some communication modules for some special hardware. There are no .NET drivers for these. The C# code is there to maintain database communication and includes some logic related to CardSpace and other security options. The Java class is a third-party encoding module which is created by an outside party which calculates a special hash code over data in the database and does some additional processing and which controls yet another piece of hardware.

Biggest problem: no network communications! It will run on a special computer which has no network hardware installed. It's a stand-alone Windows XP system. While COM, Java and .NET are okay, I cannot use any TCP/IP communications on this system.

This would be my next project if I accept it. Already, it's giving me a headache so I think I'll skip this chance, although it does have an interesting mixture of several different languages. I think I'll just tell them to invest a number of 6 digits to buy new hardware instead of spending an amount of nearly 5 digits for 28 days of my work...

---

A few details about the project that I can share:

The Delphi code is able to connect to a PBX system through a COM port which it uses to send faxes, send and receive SMS messages and to receive simple commands by just entering digits with a phone after calling in. A whole system has been written for this, all based on WIN32 code.

The Java code is a client-side module to communicate with a robotics system that monitors the environment, handles a few delicate objects and does constant measurements of those objects. It's in Java so it's platform-independent. The communication between the Java client and the robotic hardware is done through the network and the network hardware/drivers don't like additional chatter over this network. (Which is why it's disabled as much as possible. Not even Windows will get updates.)

The C# code is to collect the data from the Java module and to actually store this in-memory writing regular backups in XML, just in case something happens. It's to communicate with the Java module and a few other modules that handle the complex calculations that are written in a .NET compatible domain-specific language this customer developed themselves. These modules don't support COM, thus the c# wrapper.

The client now needs an operator to be near the hardware to manipulate the robotics. He can either upgrade the hardware, costing him quite a lot but it would give him better remote access which costs about EUR 250.000 to replace the ancient robotics and other hardware or he pays a few developers a tenth of that amount to get his current hardware to do the same. Personally, I think he should not be such a cheapskate but he just wants an estimate what the developers solution would cost him. The code changes aren't big since most of the functionality is already there. It's just combining it all without any TCP/IP communications that makes it more complex.

Basically, the instructions they want to give is to speed things up or slow down, send occasional reports and to send SMS warnings in case of problems. Now, they have an operating sitting next to the screen, drinking coffee all day while reading some newspaper or other magazines. And while that's fun for a few days, he's unable to find someone who wants to do this all the time, 24/7. (Yeah, they work day and night, including weekends.)

Basically, this is all I know myself. Haven't even seen the PC that it needs to be installed on but they have a few configured all in the same way so I can get one to experiment with, once this would be needed. (And it will be a Hell to debug too.)

---

On a final note, I presented the cost estimates and came up with a high enough number to convince my would-be employer to do a hardware upgrade instead. More expensive but it would maintain it's reliability.

Because of this, this Q had just become academic...

Answer 1

Regardless of whether there is any network hardware installed, it is likely that the standalone Windows XP system will still have local TCP/IP networking available. You can have programs listen on a TCP port on the localhost address (127.0.0.1) and other services connect to them to exchange information through any protocol you choose. HTTP with REST might be an appropriate choice.

This is likely to be a lot less painful that trying to integrate all those technologies together in one Franken-program.

Answer 2

Another option would be IKVM. It's a Java implementation for .NET. Please take a look at this related question, the answers there might help you.

Answer 3

JNBridge provides a Java-to-.NET bridge (and vice-versa). It's commecially supported, relatively cheap, and it works well. It's low-latency, and does not require TCP/IP or network communications. You don't need access to the Java code to call it from .NET through the bridge.

Answer 4

I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. Hope it will help you.