[TriLUG] [Fwd: java <=> C communication]

[H Brett Bolen]

Here is a message I sent to the java folk.  I'm wondering
of somebody here has any information:


   >> I have an app that sends a whole-lotta-stuff
   >> from a c++ app to a java app.  Currently we are
   >> using a 'middleware' layer from Mil contractor.
   >>
   >> We want to strip out the middleware layer, and
   >> use sockets.

bb: if there is something better than straight
      straight sockets, that would be fine.  gotta
      be SFO (simple, fast and open) though.

   >>
   >> Is there a java/c package that can send data
   >> from c (or c++) to java and vice versa?
   >>
   >> The existing messages have arrays that are
   >> varying length:
   >>
   >>    struct {
   >>       int      array_length;
   >>       Points   x[];
   >>       Symbols  s[];
   >>       Text     t[];
   >>    };
   >>
   >> The existing layer takes care of this, as well
   >> as all of the endian swapping.
   >>
   >> Has anybody used anything similar that is
   >> open sourced ( we are using linux).


thanks.
    b\375


-- 
b²

-----------------------
-- H Brett Bolen
-- TCNi
-- Phone: 919 550-0828
-- eFax : 509 752-8446



I need to use some sort of network -- there is a server and a client
( the client is the java viewer, and the server sends out
map data and other data that moves in real time -- say cars, trucks,
torpedos).  They may, but may not be on the same machine.

The java app doesn't pull the data, it mostly just takes messages
and draws ( as in 'apply the polygons to the screen' )the data.  It
does send some user interface info to the server ( such as turn on
bathy and topo lines, etc).

This problem should be solved already -- send large structs
with varying sized arrays from a c program to a java program.

Corba is not the answer -- we want something that is simple
and fast ( and open source  -- all the source code must be
delivered with the system).

Also we have an endian problem -- if there are ways to solve
that pass it on.  The messages are pretty much fixed.  I can
write the swap code on the server side if necessary.

any other idea?

Embedded responses below:


Jeff Knaus wrote:

   > So, can you modify the C++ code?

Yes.


   >
   > Does it need to act as a "server" or can you just invoke the c++ methods
   > directly from your Java app?

Yes -- c++ server,  java viewer as well as an X viewer.  The viewer
machines will need to be different boxes.


   >
   > If the answer is the latter, you can just use JNI to wrap the c++ app in
   > Java classes that expose the interfaces that you want to call.

No JNI -- different boxes.

   >
   > I'm presuming that the Java app is "pulling" data from the c++ app.

No.  Things move,  If a truck moves from P1 to P2, then I get updates
telling me to redraw the truck at the new position.

   >
   > If you really want to use sockets, I'd recommend wrapping the c++ app in
   > Java classes (as described above), write your "server" code in Java
   > (using ServerSocket and friends), letting JNI perform your "marshalling"
   > b/w c++ and Java, then stream the data over the socket via an ObjectStream.

Writing the server in java is not an option.  there are a lot of lines
of code in the geo server, and whole-lotta cpu computations ( round earth
to flat screen projections) and custom database lookups.

You might be saying to create a java shell around the c++ app:

      --- server box --               -- client box --
      =================               ================
JavaShell(  c++ geoserver)  <====>    Java Viewer
            |                    |
            |                    \ -- sockets
             \ -- JNI


This could work, although I am worried about performance.  I'm not
sure the 'customer' would like this approach, due to the extra
step.

I got to believe that this is a common problem and has been
solved before.

When I worked on a homebrew corba compiler we did something like
this:


       message = fixed portion + variable portion.
       replace pointers in fixed portion with indexes
           into the variable portion.
       handle endian if necessary.
       send the buffer.

Because the corba app was generating c++ code, we had some
advantages ( we could automate the endian swapping code).

   >
   > -- Jeff
   >
   > H Brett Bolen wrote:
   >
   >>
   >>
   >> -------- Original Message --------
   >> Subject: c++ communications.
   >> Date: Thu, 13 Jun 2002 08:47:32 -0400
   >> From: H Brett Bolen <wingedlizard at nc.rr.com>
   >> Reply-To: wingedlizard at nc.rr.com
   >> To: "Juglist at Rtpjug.Org" <juglist at rtpjug.org>
   >>


-- 
b²

-----------------------
-- H Brett Bolen
-- TCNi
-- Phone: 919 550-0828
-- eFax : 509 752-8446