Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Interplatform (interprocess, interlanguage) communication Date: Fri, 03 Feb 2012 22:44:54 +0100 Lines: 90 Message-ID: <9p32qmFcrnU1@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net tQH5UFEBgjCH4FUEHyStzweMfjB89PR6YCejmUfohd3QnjXVc= Cancel-Lock: sha1:ykSJLWrUNlRxKgvcJ529+YY7B3c= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11724 On 02/03/2012 08:52 PM, Stefan Ram wrote: > =BBX=AB 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. > > =BBReliability=AB means little risk of creating problems, little > risk of failure at run-time. (It might help when the client > [=3DJava 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 =BBproc=AB with =BBexec=AB and then use > > BufferedWriter out =3D new BufferedWriter(new > OutputStreamWriter(proc.getOutputStream())); > BufferedReader in =3D new BufferedReader(new > InputStreamReader(proc.getInputStream())); A pipes is just 1:1 communication and only in 1 direction. > 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. You can, but what do you do with the ever increasing file? This is not=20 reliable since the filesystem will fill up at some point. > 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 =BBcopy con file=AB. > > 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. You can as well use a packet sniffer (Wireshark for example). If you=20 use a standard protocol you'll typically have encoding functionality in=20 the tool. > 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)? That would be a clumsy approach IMHO. I'd pick a higher level protocol such as - SOAP (XML based, ubiquitous) - CORBA (a little out of fashion but quite efficient in terms of network = transport) Advantage: you can focus on definition of the API and need not take care = of all the nifty details. Choice should also depend on the availability = for language X, of course. Kind regards robert