You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Richard Liang <ri...@gmail.com> on 2006/01/09 10:41:59 UTC
NIO Component improvement
Hi there:
Recently, My colleague Paulex and I are looking at the code contributed
by IBM (Tim). We spend most of our time on NIO, and find there are some
defects in this component. We will submit the defects in Harmony JIRA,
and hopefully we can contribute patches to fix these defects.
Thanks a lot.
--
Richard Liang
China Software Development Lab, IBM
Re: NIO Component improvement
Posted by Vladimir Strigun <vs...@gmail.com>.
On 1/19/06, Anthony Green <gr...@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.
Thanks,
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
>
>
>
Re: NIO Component improvement
Posted by Anthony Green <gr...@redhat.com>.
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
Re: NIO Component improvement
Posted by Yang Paulex <pa...@gmail.com>.
Agree with you that the relation with java.net package is also one of our
main concern about SocketChannel, etc. And basically we took similiar
approach to implement it.
I've put the details into JIRA. Pls. refer to
https://issues.apache.org/jira/browse/HARMONY-27
Some implementation difference with your solution is as below:
1. Use a factory class to access Socket implementation classes, so that the
PlainXXXSocketImpl can be hide by package private access.
2. Refactored the current Harmony java.net implementations, and implement
network channels based on them.
Another comment about the error code is:
Harmony has a port library already, which has covered most functions nio
needed, and has defined platform independent error codes. I think this is
easier to use, and will make our library codes can be ported more easily, so
I suggest we leverage Harmony port library as much as possible.
I've tested the solution, and it works fine. I will post step by step
details later, or I can just upload my modifications:).
2006/1/19, Vladimir Strigun <vs...@gmail.com>:
>
> We also have been thinking about implementation of socket channels
> from java.nio package. One of the concerns we had is related to the
> fact that java.nio.channels API provides methods to access regular
> java.net socket classes via corresponding methods of socket channels.
> Since socket implementations are typically located in java.net package
> and have package private visibility one has to create the new socket
> implementations for the java.nio package. Having in mind that the
> functionality for them has many things in common it could make sense
> to share socket implementations between the java.net and java.nio
> packages.
>
> 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.
>
> Thanks,
> Vladimir Strigun, Intel Middleware Products Division.
>
>
> On 1/12/06, Paulex Yang <pa...@gmail.com> wrote:
> > Hi, everybody
> >
> > I'm Paulex of China Software Development Lab, IBM, and I'm working with
> > Richard on the nio improvement. I found that the network related
> > channels in java.nio.channels are not implemented in the class library
> > code, so I will raise a JIRA request on this today. and we will start to
> > contribute an implementation of these classes. Hopefully they can be
> > accepted and helpful:).
> >
> > P.S. As a declaration, I confirm that:
> > I have read Apache Harmony Contribution Policy and already have a
> > completed questionnaire on file. :-)
> >
> > Richard Liang wrote:
> >
> > > Geir Magnusson Jr wrote:
> > >
> > >> Defects? In software? Can't be :)
> > >>
> > >> Thanks, and welcome.
> > >>
> > >> Please read our comntribution policy :
> > >>
> > >> http://incubator.apache.org/harmony/contribution_policy.html
> > >>
> > >> Please ensure that you will be able to satisfactorily contribute to
> > >> the NIO area
> > >>
> > >> geir
> > >>
> > >> Richard Liang wrote:
> > >>
> > >>> Hi there:
> > >>>
> > >>> Recently, My colleague Paulex and I are looking at the code
> > >>> contributed by IBM (Tim). We spend most of our time on NIO, and find
> > >>> there are some defects in this component. We will submit the defects
> > >>> in Harmony JIRA, and hopefully we can contribute patches to fix
> > >>> these defects.
> > >>>
> > >>> Thanks a lot.
> > >>>
> > >>
> > > Hello Geir,
> > >
> > > Thanks for your reminder.
> > >
> > > Yes, I have read Apache Harmony Contribution Policy and already have a
> > > completed questionnaire on file.
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
>
>
--
Paulex Yang
China Software Development Labotary
IBM
Re: NIO Component improvement
Posted by Rodrigo Kumpera <ku...@gmail.com>.
I have a few comments to make.
First, don't use Microsoft Word, please. Having this on the wiki would
be wonderful.
Socket and SocketChannel have some very weird strange relationship:
1)Socket and ServerSocket must be implemented in terms of SocketImpl,
as a user can supply a custom SocketImpl as constructor parameter for
both.
2)(Server)SocketChannel uses a service provider interface, SelectorProvider.
This mean to implement this mess, subclasses of SocketImpl,
SocketChannel and ServerSocketChannel must be implemented.
My understanding is that there should be a single class with and
network code, and that one is a SocketImpl subclass. What you do is
have package private methods shared between the implementation os
SocketImpl and SocketChannel.
The same applied to datagram sockets.
Rodrigo
On 1/18/06, Vladimir Strigun <vs...@gmail.com> wrote:
> We also have been thinking about implementation of socket channels
> from java.nio package. One of the concerns we had is related to the
> fact that java.nio.channels API provides methods to access regular
> java.net socket classes via corresponding methods of socket channels.
> Since socket implementations are typically located in java.net package
> and have package private visibility one has to create the new socket
> implementations for the java.nio package. Having in mind that the
> functionality for them has many things in common it could make sense
> to share socket implementations between the java.net and java.nio
> packages.
>
> 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.
>
> Thanks,
> Vladimir Strigun, Intel Middleware Products Division.
>
>
> On 1/12/06, Paulex Yang <pa...@gmail.com> wrote:
> > Hi, everybody
> >
> > I'm Paulex of China Software Development Lab, IBM, and I'm working with
> > Richard on the nio improvement. I found that the network related
> > channels in java.nio.channels are not implemented in the class library
> > code, so I will raise a JIRA request on this today. and we will start to
> > contribute an implementation of these classes. Hopefully they can be
> > accepted and helpful:).
> >
> > P.S. As a declaration, I confirm that:
> > I have read Apache Harmony Contribution Policy and already have a
> > completed questionnaire on file. :-)
> >
> > Richard Liang wrote:
> >
> > > Geir Magnusson Jr wrote:
> > >
> > >> Defects? In software? Can't be :)
> > >>
> > >> Thanks, and welcome.
> > >>
> > >> Please read our comntribution policy :
> > >>
> > >> http://incubator.apache.org/harmony/contribution_policy.html
> > >>
> > >> Please ensure that you will be able to satisfactorily contribute to
> > >> the NIO area
> > >>
> > >> geir
> > >>
> > >> Richard Liang wrote:
> > >>
> > >>> Hi there:
> > >>>
> > >>> Recently, My colleague Paulex and I are looking at the code
> > >>> contributed by IBM (Tim). We spend most of our time on NIO, and find
> > >>> there are some defects in this component. We will submit the defects
> > >>> in Harmony JIRA, and hopefully we can contribute patches to fix
> > >>> these defects.
> > >>>
> > >>> Thanks a lot.
> > >>>
> > >>
> > > Hello Geir,
> > >
> > > Thanks for your reminder.
> > >
> > > Yes, I have read Apache Harmony Contribution Policy and already have a
> > > completed questionnaire on file.
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
>
>
Re: NIO Component improvement
Posted by Vladimir Strigun <vs...@gmail.com>.
We also have been thinking about implementation of socket channels
from java.nio package. One of the concerns we had is related to the
fact that java.nio.channels API provides methods to access regular
java.net socket classes via corresponding methods of socket channels.
Since socket implementations are typically located in java.net package
and have package private visibility one has to create the new socket
implementations for the java.nio package. Having in mind that the
functionality for them has many things in common it could make sense
to share socket implementations between the java.net and java.nio
packages.
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.
Thanks,
Vladimir Strigun, Intel Middleware Products Division.
On 1/12/06, Paulex Yang <pa...@gmail.com> wrote:
> Hi, everybody
>
> I'm Paulex of China Software Development Lab, IBM, and I'm working with
> Richard on the nio improvement. I found that the network related
> channels in java.nio.channels are not implemented in the class library
> code, so I will raise a JIRA request on this today. and we will start to
> contribute an implementation of these classes. Hopefully they can be
> accepted and helpful:).
>
> P.S. As a declaration, I confirm that:
> I have read Apache Harmony Contribution Policy and already have a
> completed questionnaire on file. :-)
>
> Richard Liang wrote:
>
> > Geir Magnusson Jr wrote:
> >
> >> Defects? In software? Can't be :)
> >>
> >> Thanks, and welcome.
> >>
> >> Please read our comntribution policy :
> >>
> >> http://incubator.apache.org/harmony/contribution_policy.html
> >>
> >> Please ensure that you will be able to satisfactorily contribute to
> >> the NIO area
> >>
> >> geir
> >>
> >> Richard Liang wrote:
> >>
> >>> Hi there:
> >>>
> >>> Recently, My colleague Paulex and I are looking at the code
> >>> contributed by IBM (Tim). We spend most of our time on NIO, and find
> >>> there are some defects in this component. We will submit the defects
> >>> in Harmony JIRA, and hopefully we can contribute patches to fix
> >>> these defects.
> >>>
> >>> Thanks a lot.
> >>>
> >>
> > Hello Geir,
> >
> > Thanks for your reminder.
> >
> > Yes, I have read Apache Harmony Contribution Policy and already have a
> > completed questionnaire on file.
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: NIO Component improvement
Posted by Paulex Yang <pa...@gmail.com>.
Hi, everybody
I'm Paulex of China Software Development Lab, IBM, and I'm working with
Richard on the nio improvement. I found that the network related
channels in java.nio.channels are not implemented in the class library
code, so I will raise a JIRA request on this today. and we will start to
contribute an implementation of these classes. Hopefully they can be
accepted and helpful:).
P.S. As a declaration, I confirm that:
I have read Apache Harmony Contribution Policy and already have a
completed questionnaire on file. :-)
Richard Liang wrote:
> Geir Magnusson Jr wrote:
>
>> Defects? In software? Can't be :)
>>
>> Thanks, and welcome.
>>
>> Please read our comntribution policy :
>>
>> http://incubator.apache.org/harmony/contribution_policy.html
>>
>> Please ensure that you will be able to satisfactorily contribute to
>> the NIO area
>>
>> geir
>>
>> Richard Liang wrote:
>>
>>> Hi there:
>>>
>>> Recently, My colleague Paulex and I are looking at the code
>>> contributed by IBM (Tim). We spend most of our time on NIO, and find
>>> there are some defects in this component. We will submit the defects
>>> in Harmony JIRA, and hopefully we can contribute patches to fix
>>> these defects.
>>>
>>> Thanks a lot.
>>>
>>
> Hello Geir,
>
> Thanks for your reminder.
>
> Yes, I have read Apache Harmony Contribution Policy and already have a
> completed questionnaire on file.
>
--
Paulex Yang
China Software Development Lab
IBM
Re: NIO Component improvement
Posted by Richard Liang <ri...@gmail.com>.
Geir Magnusson Jr wrote:
> Defects? In software? Can't be :)
>
> Thanks, and welcome.
>
> Please read our comntribution policy :
>
> http://incubator.apache.org/harmony/contribution_policy.html
>
> Please ensure that you will be able to satisfactorily contribute to
> the NIO area
>
> geir
>
> Richard Liang wrote:
>
>> Hi there:
>>
>> Recently, My colleague Paulex and I are looking at the code
>> contributed by IBM (Tim). We spend most of our time on NIO, and find
>> there are some defects in this component. We will submit the defects
>> in Harmony JIRA, and hopefully we can contribute patches to fix these
>> defects.
>>
>> Thanks a lot.
>>
>
Hello Geir,
Thanks for your reminder.
Yes, I have read Apache Harmony Contribution Policy and already have a
completed questionnaire on file.
--
Richard Liang
China Software Development Lab, IBM
Re: NIO Component improvement
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Defects? In software? Can't be :)
Thanks, and welcome.
Please read our comntribution policy :
http://incubator.apache.org/harmony/contribution_policy.html
Please ensure that you will be able to satisfactorily contribute to the
NIO area
geir
Richard Liang wrote:
> Hi there:
>
> Recently, My colleague Paulex and I are looking at the code contributed
> by IBM (Tim). We spend most of our time on NIO, and find there are some
> defects in this component. We will submit the defects in Harmony JIRA,
> and hopefully we can contribute patches to fix these defects.
>
> Thanks a lot.
>