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 <[EMAIL PROTECTED]>: > > 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 > > > > > > > > > -- Paulex Yang China Software Development Labotary IBM
