Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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 <a href="http://hg.openjdk.java.net/jdk7/hotspot-svc/jdk/file/b6d6877c1155/src/windows/classes/java/net/DualStackPlainSocketImpl.java" rel="noreferrer">DualStackPlainSocketImpl.java</a>)</p> <p>To answer your second question: what's Java's algorithm to find the default interface on windows -- checkout getDefaultIPv6Interface method in <a href="http://hg.openjdk.java.net/jdk7/hotspot-svc/jdk/file/343253d05123/src/windows/native/java/net/net_util_md.c" rel="noreferrer">net_util_md.c</a> (don't let the v6 fool you -- i believe it's used for v4 as well).</p> <p>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.</p> <p>Think Java application servers that handle huge amounts of data without a hitch.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload