Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11734 > unrolled thread

Re: Interplatform (interprocess, interlanguage) communication

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#11734 — Re: Interplatform (interprocess, interlanguage) communication

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

[toc] | [next] | [standalone]

#11737

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?

[toc] | [prev] | [next] | [standalone]

#11738

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

[toc] | [prev] | [next] | [standalone]

#11739

Jan Burse schrieb:
> 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
>

Oops, 4 solutions and 1 finger-wagging.

[toc] | [prev] | [next] | [standalone]

#11746

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web