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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > >
