On Wed, 2006-01-18 at 21:51 +0300, Vladimir Strigun wrote: > Attached document contains a proposal describing an approach which is > trying to enforce portability of nio socket channels implementation by > moving supporting functions up to java layer and by sharing the code > between java.net's socket implementations and socket channels in > java.nio package thus reducing the amount of java code and number of > native methods in both packages.
If I understand your document properly, this is similar to how we handle things in GNU Classpath (see gnu.java.net.PlainSocketImpl). One difference is that we throw exceptions in the JNI code. As you mention in your document, this has the disadvantage of resulting in a JNI class lookup -- but in your example, don't you have to do a second JNI call to get the error string? (BSDSocketErrors.getMessage(res)). (For GCJ, we implement this code in CNI - not JNI. It's simpler and there's zero overhead between the Java and C++ code - so we can throw exceptions in C++ code with no JNI name lookups.) AG
