I have a program written in C# that receives data from a third party server and processes it into a series of integers (they are streaming rapidly). The program is written in C# because the third party provides classes to process the data, but only offers them in C#. I would like to take these integers and use them in a streaming way in a Java program (so as soon as they are streamed and processed by the C# program, I would like to use the integers in the Java program). The second program is in Java because another third party only offers their classes (which are required) in Java. So my guess for what to do is either-
Look for a program that runs C# classes in Java, and then include the C# classes that process the incoming data directly into my Java program [This doesn't seem too promising - I can't seem to get jni4net, which was suggested in other posts, to work]
or
Write another program in C# that saves to a particular memory location the integers that are being processed. Compile the program. Then run the executable from within the Java source code and have some sort of callback written in the Java code that picks up when the integers at the specific memory locations are changed and record what these new numbers are [Not sure how to start on this!]
Does anyone have any suggestions for what might be the least painful approach?
It sounds like you want some form of inter-process communication mechanism.
As such, anything allowing communication could be employed:
Named Pipes
Sockets
TCP connection
Shared memory
Out of the options I would recommend named pipes as they're the simplest to grasp and have no problems with ports not being available etc.
See: How to open a Windows named pipe from Java?
And: Using Named Pipes for IPC in C#
This post: Using Named Pipes to communicate between C# and Java describes and end-to-end means of using pipes from both environments.
You can merge the Java and C# programs into one and use JNI to bridge the C#/Java interface. JNI basically allows you to call C# methods from Java and vice versa. I guess this would be equally hard to code as sockets, plus there would be some speedup.
More info here: http://www.codeproject.com/Articles/245622/Using-the-Java-Native-Interface-in-Csharp
I had to do something similar in the past in order to get data from a Java system into Excel (via the RTD API), and ended up going with the socket protocol approach.
If you have a really simple dataset (like the stream of integers you mention above), this should be very straighforward - just look at the documentation for the Java Socket and ServerSocket classes, and the corresponding C# Socket class.
If you end up with a more complex API, with multiple messages etc. you might want to take a look at Google Protocol Buffers, as there are both .Net and Java implementations around.
Related
I've been doing some programming in Java and some in C but now I need to sort of use both together.
Here's the situation, I'm using Hadoop/Hbase to process and store a lot of data but I'm using C/Cuda to do number crunching on the data. Is there a stable/mature/common way to take data (it's basically a log file) in Java and pass it to a C program, which C processes the data it stores it as a linked list that is then accessible by the Java app?
I might not be searching for the right thing, but so far I found JavaCPP, which is good but seems to involve both programs together. Because Java handles the data flow and C handles the processing of the data, I thought it might be better to keep them as independent programs that can communicate to each other as opposed to a single program that may become confusing. But I'm totally flexible so any suggestions/solutions are welcomed.
You may find it easier to keep the programs testable and clear if you leave them separate and then use a client-server approach, or simply choose a common file format and have the latter steps poll the output directory for new files to process.
To make it easier to define file formats across different languages, consider a package like Apache Thrift or Google Protocol Buffers.
Here what I have on the top of my head
1. run C program using command line from java app.
2. Use JNI/JNA
3. Implement your own "client-server" architecture. It sounds complicated but in some cases it may be the best and the simplest solution.
4. Communicate using Web service, SOAP, REST, whatever.
I hope this is helpful for the beginning.
You are welcome to ask more specific questions once you have.
I would like to know how to do to get variables of a C++ running program from my Java application. I think I have to do an API, but I don't know how to start this. In fact, I want to get information about packets in the Ekiga softphone. I localized what I want in Ekiga's main.cpp :
double lost = mw->priv->current_call->get_lost_packets();
double late = mw->priv->current_call->get_late_packets();
double out_of_order = mw->priv->current_call->get_out_of_order_packets();
I think what you need is JNI: http://en.wikipedia.org/wiki/Java_Native_Interface
You have to create an dll that will have methods that return this values and have a java class with native methods that will use this dll.
Sound like you want to implement a bridge layer using technologies such JNI or JNA.
A second option would be writing a Web service or Message passing layer between the two languages. I would avoid CORBA for such a simple problem (actually, I would avoid CORBA period hehehe).
Either that or have the C++ write the data to a Database, File, etc and write Java code to read it.
You can't directly access c++ variables from a different process. I do not know if ekiga already provides a way to get the data from external programs, so here are a few ways to get at the data (all involve modifying ekiga itself in some way).
Add a socket to listen for connections within the ekiga program and make your java program connect to this socket using client sockets. This way you can send the information to the connected java program wenever these values change.
Start the java Program within ekiga or make your java program start ekiga as a native method call. Both of these involve jni and result in both parts (ekiga and java program) running as a single process.
The first is simpler and less error prone, however you need some basic knowledge about network programming in both java and c++.
I want some help on a way to transfer data from a python web application to a java desktop application.
What I am doing is having java listen on a port and receive data. But I have no idea how I would send data from python to an open port on a server.
What my question is how would I send data from a python web app to an open port on a computer. And would there be any problems like data types and any other things?
This is a really large question as there are many ways to send data back and forth between server (your java app) and client (your python app).
Your situation is not quite clear (what exactly is your "python web application"?), but you may want to look into XML-RPC. XML-RPC is extremely simple to use and set up, and takes care of "problems like data types and any other things". You basically just set up some functions on your server that the client can call, and have python call them. Arguments are neatly wrapped up by teh client and unwrapped by the server. Return values are the same. It is a simple and clean interface.
For python making calls to the server, you want to use the xmlrpclib module.
To set up an XMLRPC server in java, you have many options. I'm not a Java guy, but I'm sure it is quite simple on that side as well.
There are many good xml-rpc tutorials. Here is one that covers client and server in python.
Like I said earlier, there are MANY options available to you. XML-RPC is a good and simple way to get your feet wet, without really limiting you very much (eg: it has built in fault handling).
Good luck!
If you use a platform independent data format -- xml, json, yaml, ascii txt, ... -- to represent numbers, you have really nothing to worry about.
If you can not afford the inefficiencies of above, then a binary protocol is required.
Java uses network byte ordering (or Big Endian). Python uses the native host byte ordering, OR, you can specify the byte ordering. Here you want to specify Big Endian (sec 7.3.2.1) in writing your numeric data.
Why not use sockets in python too and send it to the java server. Java does not know that the end client is python, what it reads is just data(bytes). I have done this, and it works seamlessly.
See the python's struct module for more details on converting datatypes
I have two separate programs, one in Java and one in C++, both running on Windows.
We need to do bidirectional interprocess communication between the two.
Up until now, we were using this awkward solution of writing to text files and reading them on the other side, where the producer would generate a .lock file when it's done writing and the consumer would remove that when it's done reading... like I said, awkward.
If we were on *nix, we would use a pipe using popen() on the C++ and RadomAccessFile on the Java side. It seems to work well.
What can we do on Windows? Can we use named pipes?
Thank you.
Take a look at google's protocol buffers: http://code.google.com/apis/protocolbuffers/docs/overview.html
This provides a serialization mechanism between Java and C++.
And then google for a C++ stream implementation for sockets and send messages between java and C++ via TCP.
I'd recommend sockets for IPC if you are using a mix of Java and C++. Sockets seem like a more robust solution than writing/locking a shared file :).
However, I'll point you to this SO post... It seems like you can use named pipes on the .NET side and RandomAccessFile on the Java end: http://v01ver-howto.blogspot.com/2010/04/howto-use-named-pipes-to-communicate.html
Give that a shot... it looks promising
I know of at least one post which has same words like this. But this is not exactly same as that post. I'm trying to work a way to "share" data between a .NET and Java application. I'm not concerned about objects, but just plain strings if u like.
I have a .NET application capturing real-time data and a Java application which has capability to analyze and work on this data. I'm looking for ways to re-use this same java app without coding it entirely in .NET.
My problem is that the data is "fairly" REAL-Time (.NET), and so has to be the analysis (Java). I can live with microsecond delays but I can't afford one second delay. WebServices, Queues (as in Messaging Queues), RDBMS are some of the options I can think of. Is there any better way?
Or has anybody got some real performance numbers for the solutions I mentioned above to select one of them? And just to get started: RDBMSs' are not "THAT" good for concurrent (connections doing) insertion/updation/reading, at least with the crude way of doing DBMS stuff. (Deadlocks?)
What are "objects" if not a mechanism for describing "data"? But I digress - I suspect I would look at a TCP socket between the two. If the data is very basic, then fine - just write directly to the stream; if there is any complexity, perhaps use something like "protocol buffers" to provide an easy way of reading/writing dense data to a stream without having to write every last byte yourself.
I think microsecond delays are going to be a challenge for any approach here... will millisecond delays do?
For completeness:
Another possible is to use Named pipes, it should be pretty quick, and I'd imagine (being a java guy I can only imagine) that .NET has native support for them. The down side is that on windows you'll have to either write a JNI extension or use a library like JNA to poke around at the Win32 API from Java.
Sounds like a local socket could do. The latency should be in low ms or less.
Depending on your program you may get some milage out of what #Cowan reports in answer to 'Any Concept of shared memory in java', his answer is: Any concept of shared memory in Java
In summary: he say's that you can use memory mapped files between two processes on the same machine. This in theory could work between .NET and java assuming .NET has some memory mapped file support.
Different machines communicate with each other by sending messages into sockets. Please check the below link for example.
Socket programming in the real world
Answers provided here are great. One idea that might be of interest, but is probably asking for more trouble than it's worth is to load both VMs in a single process (both the JVM and the CLR can be loaded within a native Windows application) and give them access to native code. Java via JNI and .Net via the mapping functions to native code that they allow.
You could also leverage native queue semaphores to wake up a thread on one side or the other when data is updated.
While JNI transitions are expense, they would probably still be faster than the native local socket implementation.
How is your Java application currently deployed? It sounds to me like you're willing to make some modification to it, so I'm assuming you have access to the source code.
I know this is a little out there, but could you compile the Java application in the J# compiler, so that your .NET app has native access to it?
You can convert your compiled java application to .NET by IKVM. After that you can change logic of your .NET application so it will not make data transfers to Java application, but just call data processing code written in Java as it were written and compiled for .NET.
There are a number of JMS servers which support .NET and Java clients. These can perform messages in under a millisecond.
However you might like to try an RPC solution like Hessian RPC or Protobuf RPC. These can achieve lower latencies and can give the appearance of direct calls between platforms. These support .NET and Java as well.