Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #11734
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Interplatform (interprocess, interlanguage) communication |
| Date | 2012-02-04 13:57 +0100 |
| Organization | albasani.net |
| Message-ID | <jgj9vu$jmr$1@news.albasani.net> (permalink) |
| References | <IPC-20120203200443@ram.dialup.fu-berlin.de> |
I would add to the list: Shared Memory Stefan Ram schrieb: > »X« below is another language than Java, for example, > VBA, C#, or C. > > When an X process and a Java process have to exchange > information on the same computer, what possibilites are > there? The Java process should act as a client, sending > commands to the X process and also wants to read answers > from the X process. So, the X process is a kind of server. > > My criteria are: reliability and it should not be extremely > slow (say exchanging a string should not take more than > about 10 ms). The main criterion is reliability. > > »Reliability« means little risk of creating problems, little > risk of failure at run-time. (It might help when the client > [=Java process] can reset the communication to a known and > sane start state in case of problems detected at run-time.) > > The host OS is Windows, but a portable solution won't hurt. > > A list of possibilities I am aware of now: > > Pipes > > I have no experience with this. I heard one can establish > a new process »proc« with »exec« and then use > > BufferedWriter out = new BufferedWriter(new > OutputStreamWriter(proc.getOutputStream())); > BufferedReader in = new BufferedReader(new > InputStreamReader(proc.getInputStream())); > > Files > > One process writes to the end of a file, the other reads > from the end of the file? - I never tried this, don't know > if it is guaranteed to work that one process can detect and > read, whether the other has just appended something to a file. > > What if the processes run very long and the files get too > large? But OTOH this is very transparent, which makes it easy > to debug, since one can open the files and directly inspect > them, or even append commands manually with »copy con file«. > > Sockets > > This is slightly less transparent than files, but has the > advantage that it becomes very easy to have the two > processes running on different computers later, if this > should ever be required. Debugging should be possible > by a man-in-the-middle proxy that prints all information > it sees or by connecting to the server with a terminal. > > JNI > > JNI might be used to access code written in C or > ABI-compatible languages. This should be fast, but I heard > that it is error prone to write JNI code and needs some > learning (code less maintainable)? >
Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread
Re: Interplatform (interprocess, interlanguage) communication Jan Burse <janburse@fastmail.fm> - 2012-02-04 13:57 +0100
Re: Interplatform (interprocess, interlanguage) communication markspace <-@.> - 2012-02-04 10:55 -0800
Re: Interplatform (interprocess, interlanguage) communication Jan Burse <janburse@fastmail.fm> - 2012-02-04 20:24 +0100
Re: Interplatform (interprocess, interlanguage) communication Jan Burse <janburse@fastmail.fm> - 2012-02-04 20:29 +0100
Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 18:37 -0500
csiph-web