Using a java socket from JNI / C++ code

后端 未结 5 1528
抹茶落季
抹茶落季 2021-01-02 05:02

I have a java app that creates a socket to talk to a server process, eg new java.net.Socket(String host, int port). This app includes a bunch of legacy c++ code that needs t

相关标签:
5条回答
  • 2021-01-02 05:30

    For your first question, if you have a java.net.Socket object reference in your JNI code, you can invoke methods on it, and so you can read and write data via the socket.

    0 讨论(0)
  • 2021-01-02 05:34

    Beware of solutions that poke around in JVM implementation specifics, they are liable to break in the future or with a different vendors VM. There is a way to do this portably using java.nio APIs. There are methods for communicating with channels from native code without copying buffers to/from the java heap.

    The basic idea will be to create a java.nio.SocketChannel in your java code to open the connection. Then in the C++ use NewDirectByteBuffer to create a java.nio.ByteBuffer instance that can be passed to the read/write methods of the channel instance.

    Look at JNI Enhancements Introduced in Version 1.4 of the Java 2 SDK and New I/O APIs for the details.

    0 讨论(0)
  • 2021-01-02 05:37

    I can't think of a reason why Java would choose a ''better' local interface than th enative code. All it does is call the native code, very similarly to what you have yourself. You might be seeing something that is order-dependent rather than Java-dependent.

    0 讨论(0)
  • 2021-01-02 05:48

    Your second question-

    You can always 'bind' to the local interface you want (just need the the Ip address for it)

    public void bind(SocketAddress addr) throws SocketExceptionBinds this DatagramSocket to a specific address & port

    0 讨论(0)
  • 2021-01-02 05:53

    To answer your first question: if it's possible to reuse Java's socket from within the native code -- yes it is possible, but I would not recommend it (you would tie yourself to the internals of a specific implementation/version); but if you really must: use reflection to get access to java.io.FileDescriptor on the java.net.SocketImpl then use sun.misc. JavaIOFileDescriptorAccess's get method to get the native socket descriptor. Checkout DualStackPlainSocketImpl.java)

    To answer your second question: what's Java's algorithm to find the default interface on windows -- checkout getDefaultIPv6Interface method in net_util_md.c (don't let the v6 fool you -- i believe it's used for v4 as well).

    I would advise that you open and use the socket either from the C (JNI) code or from the Java code, preferably the later, as you'll find that cleanup and error handling is best handled in the code that manages the socket. The idea of opening the socket in Java and passing byte buffers from C (JNI) is perfectly sane, and you should not find any problems with the heap on reasonable buffer sizes and proper deallocation in the JNI code.

    Think Java application servers that handle huge amounts of data without a hitch.

    0 讨论(0)
提交回复
热议问题