Interplatform (interprocess, interlanguage) communication

Discussion in 'Java' started by Stefan Ram, Feb 3, 2012.

  1. Stefan Ram

    Stefan Ram Guest

    »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)?
    Stefan Ram, Feb 3, 2012
    #1
    1. Advertising

  2. On 02/03/2012 08:52 PM, Stefan Ram wrote:
    > »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()));


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


    You can as well use a packet sniffer (Wireshark for example). If you
    use a standard protocol you'll typically have encoding functionality in
    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
    Robert Klemme, Feb 3, 2012
    #2
    1. Advertising

  3. Stefan Ram

    Arne Vajhøj Guest

    On 2/3/2012 2:52 PM, Stefan Ram wrote:
    > »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()));


    That would require the client to start the server.

    Does not look as a good solution.

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


    It should work, but it will be slow.

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


    That would be my choice.


    > 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)?



    JNI would mean single process.

    It does fit with your problem description.

    JNI is a bit tricky, but it is not more difficult than
    many other things. But since Java programmers very rarely
    use JNI, then most Java programmers never learn JNI properly
    with the expected result. You could learn JNI if you need to.

    Arne
    Arne Vajhøj, Feb 3, 2012
    #3
  4. Stefan Ram

    Arne Vajhøj Guest

    On 2/3/2012 4:44 PM, Robert Klemme wrote:
    > On 02/03/2012 08:52 PM, Stefan Ram wrote:
    >> »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()));

    >
    > A pipes is just 1:1 communication and only in 1 direction.


    That type of pipe is bidirectional.

    And Windows named pipes are bidirectional as well.

    >> 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
    > reliable since the filesystem will fill up at some point.


    It would be possible to switchover to a new file and
    delete the old file if he really wanted to go this route.

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


    They will use socket as transport.

    But if the X language has a good SOAP toolkit, then it would
    certainly make things a lot easier.

    Arne
    Arne Vajhøj, Feb 3, 2012
    #4
  5. On 12-02-03 03:52 PM, Stefan Ram wrote:
    > »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.

    [ SNIP ]
    >
    > 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«.

    [ SNIP ]

    A logical subset of files for IPC is database tables.

    AHS
    --
    ....wherever the people are well informed they can be trusted with their
    own government...
    -- Thomas Jefferson, 1789
    Arved Sandstrom, Feb 3, 2012
    #5
  6. Stefan Ram

    Jeff Higgins Guest

    On 02/03/2012 02:52 PM, Stefan Ram wrote:
    > »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.
    >

    For Windows platform:
    <http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx>
    Prune for Java/X support, prune again for your choice of protocol.

    snip
    Jeff Higgins, Feb 3, 2012
    #6
  7. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >Sockets


    Thanks for the answers so far! So I might go for sockets,
    because I like that fact that I do not need any additional
    libraries under C (where one can use winsocks) and under
    Java (where they are part of Java SE).
    Stefan Ram, Feb 4, 2012
    #7
  8. Stefan Ram

    Jan Burse Guest

    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)?
    >
    Jan Burse, Feb 4, 2012
    #8
  9. On 03.02.2012 23:56, Arne Vajhøj wrote:
    > On 2/3/2012 4:44 PM, Robert Klemme wrote:
    >> On 02/03/2012 08:52 PM, Stefan Ram wrote:
    >>> »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()));

    >>
    >> A pipes is just 1:1 communication and only in 1 direction.

    >
    > That type of pipe is bidirectional.


    Well, that are actually two pipes aren't they? Or it's a socketpair,
    depending on platform. Also, this approach only works if the Java
    process always starts the other process. Alternatively the other
    process would start the Java process this way and we can read from
    System.in and write to System.out.

    > And Windows named pipes are bidirectional as well.


    Oh, I didn't knew that. Learn something new every day. Thanks!

    >>> 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
    >> reliable since the filesystem will fill up at some point.

    >
    > It would be possible to switchover to a new file and
    > delete the old file if he really wanted to go this route.


    Well, yes, but that soon gets nasty because of file locking etc.

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

    >
    > They will use socket as transport.
    >
    > But if the X language has a good SOAP toolkit, then it would
    > certainly make things a lot easier.


    Exactly.

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Feb 4, 2012
    #9
  10. On 02/03/2012 11:52 AM, Stefan Ram wrote:

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


    SOAP has been mentioned, but I would also look at REST. An http post
    with an XML response although less powerful, has a wider range of
    support. Using port 80/443 to get to a server also greatly simplifies
    firewall issues when the systems are remote.

    >
    > 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)?
    >

    The biggest drawback to JNI (I feel) is that it opens up all the
    disadvantages of C in a Java environment. It is difficult (for me) at
    times to determine exactly where an error actually is as I use C only
    when forced to.

    Jeff Coffield
    www.digitalsynergyinc.com
    Jeffrey H. Coffield, Feb 4, 2012
    #10
  11. Stefan Ram

    markspace Guest

    On 2/4/2012 4:57 AM, Jan Burse wrote:
    > I would add to the list:
    >
    > Shared Memory
    >



    What Java API do you use for that?
    markspace, Feb 4, 2012
    #11
  12. Stefan Ram

    Jan Burse Guest

    markspace schrieb:
    > On 2/4/2012 4:57 AM, Jan Burse wrote:
    >> I would add to the list:
    >>
    >> Shared Memory
    >>

    >
    >
    > What Java API do you use for that?
    >



    One solution would be to port MemoryFiles from
    Android to Java SE. The API of MemoryFiles is
    seen here:

    http://developer.android.com/reference/android/os/MemoryFile.html

    You can also find the source code of the classes.
    But suggesting the above has more to do with my
    obsession for memory files (just joking).

    But the following stack overflow entry lists 5 (five)
    alternative ways do deal with shared memory in Java:

    http://stackoverflow.com/questions/1491519/any-concept-of-shared-memory-in-java

    Bye
    Jan Burse, Feb 4, 2012
    #12
  13. Stefan Ram

    Jan Burse Guest

    Jan Burse, Feb 4, 2012
    #13
  14. Stefan Ram

    Roedy Green Guest

    On 3 Feb 2012 19:52:08 GMT, -berlin.de (Stefan Ram) wrote,
    quoted or indirectly quoted someone who said :

    > When an X process and a Java process have to exchange
    > information on the same computer, what possibilites are
    > there?


    TCP/IP socket.

    both talk to SQL database, presume data cached.

    both read and write same file on SSD

    JNI
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    One of the most useful comments you can put in a program is
    "If you change this, remember to change ?XXX? too".
    Roedy Green, Feb 4, 2012
    #14
  15. Stefan Ram

    Roedy Green Guest

    On Sat, 04 Feb 2012 12:50:15 -0800, Roedy Green
    <> wrote, quoted or indirectly quoted
    someone who said :


    >both read and write same file on SSD


    Let's say you used a simple RandomAccessFile. How could you implement
    a busy lock field in the file to indicate the file was busy being
    updated? or busy being read? In RAM you have test and set locks to
    check a value and set the value in one atomic operation. How could
    you simulate that without test and set hardware on the SSD? You can't
    very well share a RAM lock between separate jobs.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    One of the most useful comments you can put in a program is
    "If you change this, remember to change ?XXX? too".
    Roedy Green, Feb 4, 2012
    #15
  16. Stefan Ram

    Jan Burse Guest

    Roedy Green schrieb:
    > Let's say you used a simple RandomAccessFile. How could you implement
    > a busy lock field in the file to indicate the file was busy being
    > updated? or busy being read? In RAM you have test and set locks to
    > check a value and set the value in one atomic operation. How could
    > you simulate that without test and set hardware on the SSD? You can't
    > very well share a RAM lock between separate jobs.


    What do you want, a write lock or a read lock?
    Here is a write lock:

    Obtain the lock:
    raf = new RandomAccessFile(file, "rw");

    fo = new FileOutputStream(raf.getFD());
    fo.getChannel().lock(0, Long.MAX_VALUE, false);

    Release the lock:
    fo.close();

    raf.close();

    Maybe it can be done even simpler, but the above
    works for me over process / jvm boundaries. Can
    be also used to synchronize jvm with non-jvm code.

    Similar code I use to obtain a read lock, via an
    FileInputStream and the lock() methods third
    argument =true. Currently seems also to work on
    Android, but did not yet thoroughly test...

    Bye

    (*)
    http://docs.oracle.com/javase/1.4.2...ls/FileChannel.html#lock(long, long, boolean)
    Jan Burse, Feb 4, 2012
    #16
  17. Stefan Ram

    Arne Vajhøj Guest

    On 2/4/2012 11:50 AM, Jeffrey H. Coffield wrote:
    > On 02/03/2012 11:52 AM, Stefan Ram wrote:
    >> 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.

    >
    > SOAP has been mentioned, but I would also look at REST. An http post
    > with an XML response although less powerful, has a wider range of
    > support. Using port 80/443 to get to a server also greatly simplifies
    > firewall issues when the systems are remote.


    That is given by the HTTP transport more than the RPC style SOAP
    vs RESTful POX.

    Arne
    Arne Vajhøj, Feb 4, 2012
    #17
  18. Stefan Ram

    Arne Vajhøj Guest

    On 2/4/2012 7:59 AM, Robert Klemme wrote:
    > On 03.02.2012 23:56, Arne Vajhøj wrote:
    >> On 2/3/2012 4:44 PM, Robert Klemme wrote:
    >>> On 02/03/2012 08:52 PM, Stefan Ram wrote:
    >>>> »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()));
    >>>
    >>> A pipes is just 1:1 communication and only in 1 direction.

    >>
    >> That type of pipe is bidirectional.

    >
    > Well, that are actually two pipes aren't they? Or it's a socketpair,
    > depending on platform.


    The Java Process supports in and out.

    Whether the OS does it via single bidirectional or two unidirectional
    does not change the Java code.

    Thinking of it then two sounds more likely as Java also need to
    separate err and out - that would be a lot easier with two.

    > Also, this approach only works if the Java
    > process always starts the other process.


    Yep.

    >>>> 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
    >>> reliable since the filesystem will fill up at some point.

    >>
    >> It would be possible to switchover to a new file and
    >> delete the old file if he really wanted to go this route.

    >
    > Well, yes, but that soon gets nasty because of file locking etc.


    Some coding required.

    Arne
    Arne Vajhøj, Feb 4, 2012
    #18
  19. Stefan Ram

    Arne Vajhøj Guest

    On 2/4/2012 1:55 PM, markspace wrote:
    > On 2/4/2012 4:57 AM, Jan Burse wrote:
    >> I would add to the list:
    >>
    >> Shared Memory

    >
    > What Java API do you use for that?


    java.nio.MappedByteBuffer or some JNI I would guess.

    Arne
    Arne Vajhøj, Feb 4, 2012
    #19
  20. Stefan Ram

    Arne Vajhøj Guest

    On 2/4/2012 3:50 PM, Roedy Green wrote:
    > On 3 Feb 2012 19:52:08 GMT, -berlin.de (Stefan Ram) wrote,
    > quoted or indirectly quoted someone who said :
    >
    >> When an X process and a Java process have to exchange
    >> information on the same computer, what possibilites are
    >> there?

    >
    > TCP/IP socket.
    >
    > both talk to SQL database, presume data cached.
    >
    > both read and write same file on SSD
    >
    > JNI


    If you had bothered read the entire post, then you may have
    been able to avoid repeating those already listed in the
    post.

    Arne
    Arne Vajhøj, Feb 4, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Swapnajit Mittra
    Replies:
    0
    Views:
    433
    Swapnajit Mittra
    Dec 21, 2004
  2. Dave Bartlett

    newbie question: interprocess communication

    Dave Bartlett, May 13, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    484
    DalePres
    May 13, 2004
  3. James  Aguilar
    Replies:
    3
    Views:
    541
    Aguilar, James
    Dec 20, 2005
  4. Michael Butscher
    Replies:
    7
    Views:
    336
    Lawrence D'Oliveiro
    Jul 1, 2006
  5. exhuma.twn
    Replies:
    23
    Views:
    996
    Steve Holden
    Feb 18, 2007
Loading...

Share This Page