4

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...

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
Wim ten Brink
  • 25,901
  • 20
  • 83
  • 149
  • 2
    As I see it, Delphi has nothing to do with this. Neither does COM. You're trying to call Java code from C# code. How you initially got into the C# code is irrelevant. That revelation makes your situation much less complex. – Rob Kennedy Sep 15 '09 at 20:09
  • Although that's true, it does add some limitations to the memory model and a few other minor limitations. It mostly limits the way how I can make C# and Java communicate with one another. (I could have just reversed it, calling C# from Java through it's COM interface if it wasn't for the annoying Delphi/WIN32 code. – Wim ten Brink Sep 15 '09 at 21:15
  • The only way I can see the memory model or the host application having anything to do with it is if you want the Java code to write directly into some Delphi-allocated memory, which must be marshaled through COM. So don't do that. Let the Java code write into a C#-allocated buffer, as I assume IKVM and JNBridge must support as a basic feature, and then marshal that back to Delphi the same way you already do for everything else in the DLL. – Rob Kennedy Sep 15 '09 at 22:07

4 Answers4

4

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.

Community
  • 1
  • 1
Cesar
  • 5,488
  • 2
  • 29
  • 36
  • I've considered this for a moment, but I don't control the Java code and thus couldn't guarantee that it would work. There could be a few license problems related to this, although some minor issues can just be overlooked, if need be. – Wim ten Brink Sep 15 '09 at 20:00
2

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.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
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.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • Actually, the requirement is that there's no code that uses TCP/IP inside this project. So no open ports. I guess the system has a very strict firewall installed to prevent any of it, although I don't know the exact specifics yet. – Wim ten Brink Sep 15 '09 at 19:50
  • Sounds dodgy, especially given the other implementation restrictions. At least it sounds like you have the ability to choose not to work on this project. :) – Greg Hewgill Sep 15 '09 at 19:54
  • Yep. I've been asked to do a costs estimate first so they can continue to use current hardware for several more years. This allows me to determine if it's possible and if I even want to do it. And it allows them to see if it's really a lot cheaper than buying a better hardware solution.Right now, I'm ten times cheaper than the new hardware option, if I can still do this within 28 days without any further costs. (Unfortunately, there are other costs.) As long as my estimate stays clearly below half the hardware costs, it will be considered. – Wim ten Brink Sep 15 '09 at 21:20
1

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.

Pavel Savara
  • 3,427
  • 1
  • 30
  • 35
  • Since I convinced management that such a solution would become too complex and expensive, the question has become academic. – Wim ten Brink Nov 01 '09 at 21:55