local sockets vs. JNI

[chrisrocker90]

I have to link together a couple of programs in which a Java process
passes a TCP stream to a C++ process, which then transmits the data to
a remote host.

As I see it, I have two options.

The first is to pass the TCP stream to the C++ process by using a JNI
call. I'm not quite sure how it would work - it would just be a wrapper
to a method I would install in the C++ process I guess. But it seems
like a "tightly coupled" solution, although that might not be too bad
if it's only one method call. Also, I'm not sure how much buffering
goes on when you make a JNI call. Also, JNI code seems kind of messy
and complicated to maintain, partially because of the wierd C syntax
and the various JNI objects. The real problem I have with it is that
it's an additional layer to maintain.

The other solution sounds better initially, which is using a local TCP
connection to pass the stream to the C++ process, which would then
rewrite the stream to its own socket. I would need to figure out how to
handle sockets in C++, which from what I've seen is no picnic either.
But it would save me the headache of a third JNI layer.

However another important if not overriding consideration is speed.
Would passing it through the JNI layer be faster or slower than passing
it through the local IP stack? They both need to copy and read from a
buffer at least once, I would think.

Any thoughts or insights are welcome.

- chris

 

[res7cxbi]

Java has built-in networking capabilities. It is totally possible to
have a Java-Based Network application connect to a C++-Based Network
Process. TCP streams are more than supported in Java, along with the
Java I/O classes. You can avoid JNI calls or local socket connections
to your local C++ process. You can eliminate all these rather confusing
techniques, and make it significantly faster - as long as the Java side
and the C++ side agree to some protocol or a set of rules you make to
get these two processes to understand each other.

If you totally need to have that local C++ process along with Java,
it's probably better to do it in JNI. It is very confusing, but
probably the best way to go. I do not believe that JNI calls are
buffered - then again, Java doesn't do a lot of things with calls
passes to JNI. You have to be careful with JNI as there are no
error-checking or garbage collection in C++. And an error in the C++
process can crash the JVM, so be mindful of what you program in C++.

 

[chrisrocker90]

If you totally need to have that local C++ process along with Java,
it's probably better to do it in JNI. It is very confusing, but
probably the best way to go. I do not believe that JNI calls are
buffered - then again, Java doesn't do a lot of things with calls
passes to JNI. You have to be careful with JNI as there are no
error-checking or garbage collection in C++. And an error in the C++
process can crash the JVM, so be mindful of what you program in C++.

Thanks for your reply. Unfortunately, I do have to talk to a local C++
process - it's actually a library that has a bunch of functionality.
However, as luck would have it, the socket solution doesn't work. I can
make a local connection to the C++ process, but it then fails to send
anything via its own remote connection. Otoh, if I disable my server
socket code, then it can send data just as before - but obviously not
receive new connections.

I think the fact that the C++ program has its own customized socket
somehow is fouling things up. There's some kind of network area that
has to be initilialized, I need to include some networking and io
headers - basically, it's DOA.

So, it looks like JNI is the way to go. Just as well - working with
that yukky MFC C++ code feels like being stuck inside a machine's brain
gone amuck. At least JNI is straight C.

- Chris