harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Strigun <vstri...@gmail.com>
Subject Re: NIO Component improvement
Date Thu, 19 Jan 2006 14:06:40 GMT
On 1/19/06, Anthony Green <green@redhat.com> wrote:
> 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).

ok, I'll have a look to classpath implementation.

> 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)).

No, we don't - BSDSocketErrors contains all the error messages on the
Java layer, one more advantage of this is that since all error
messages are kept within one class they could be easily localized.

Vladimir Strigun, Intel Middleware Products Division.

> (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

View raw message