4

We have two code bases, one written in C++ (MS VS 6) and another in Java (JDK 6). Looking for creative ways to make the two talk to each other.

More Details:

Both applications are GUI applications.
Major rewrites or translations are not an option.
Communications needs to be two-way. Try to avoid anything involving writing files to disk.

So far the options considered are:

  • zero MG
  • RPC
  • CORBA
  • JNI
  • Compiling Java to native code, and then linking

Essentially, apart from the last item, this boils down to a choice between various ways to achieve interprocess communication between a Java application and a C++ application. Still open to other creative suggestions!

If you have attempted this, or something similar before please chime in with your suggestions, lessons learnt, pitfalls to avoid, etc.

Someone will no doubt point out shortly, that there is no one correct answer to this question. I thought I would tap on the collective expertise of the SO community anyway, and hope to get many excellent answers.

Kara
  • 6,115
  • 16
  • 50
  • 57
bguiz
  • 27,371
  • 47
  • 154
  • 243
  • 1
    In situations like these, where rewrites are undesirable and you would have to write the JNI glue-code, I'd highly recommend [considering JNA, and writing the JNA glue-code](http://stackoverflow.com/questions/2241685/java-native-access-doesnt-do-c-right/2242341#2242341), it's simpler, IMO. – Mark Elliot Jul 06 '11 at 01:34
  • @bguiz: How have you been going with this? Any of the suggestions been of assistance? – Ben Jaguar Marshall Aug 30 '11 at 01:49

4 Answers4

1

Well, it depends on how tightly integrated you want these applications to be and how you see them evolving in the future. If you just want to communicate data between the two of them (e.g. you want one to be able to open a file written by the other, or read a stream directly from the other), then I would say that protocol buffers are your best bet. If you want the window rendered by one of these GUI apps to actually be embedded in a panel of the other GUI app, then you probably want to use the JNI approach. With the JNI approach, you can use SWIG to automate a great deal of it, though it is dangerously magical and comes with a number of caveats (e.g. it doesn't do so well with function overloading).

I strongly recommend against CORBA, RMI, and similarly remote-procedure-call implementations, mostly because, in my experience, they tend to be very heavy-weight and consume a lot of resources. If you do want something similar to RMI, I would recommend something lighter weight where you pass messages, but not actual objects (as is the case with RMI). For example, you could use protocol buffers as your message format, and then simply serialize these back and forth across normal sockets.

Kit Ho mentioned XML or JSON, but protocol buffers are significantly more efficient than either of those formats and also have notions of backwards-compatibility built directly into the definition language.

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
1

Use Jacob ( http://sourceforge.net/projects/jacob-project ), JCom ( http://sourceforge.net/projects/jcom ), or j-Interop ( http://j-interop.org ) and use COM for communication.

bguiz
  • 27,371
  • 47
  • 154
  • 243
g051051
  • 1,021
  • 5
  • 11
1

Since you're using Windows, I'd suggest using DDE (Dynamic Data Exchange). There's a Java library available from Java Parts.

Ben Jaguar Marshall
  • 481
  • 4
  • 17
0

Dont' know how much data and what type of data you wanna transfer and communicate. But to simplify the way, I suggest using XML or Json based on HTTP protocol.

Since there are lots of library for both applications and you won't spend too much effort to implement and understand.

More, if you have additional applications to talk with, it is not hard since both tech. are cross-languages.

correct me if i am wrong

TheOneTeam
  • 25,806
  • 45
  • 116
  • 158