harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tanzer <stru...@guglhupf.net>
Subject Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Mon, 17 Jul 2006 12:44:15 GMT

On 17.07.2006, at 14:09, Richard Liang wrote:

>
>
> LvJimmy,Jing wrote:
>> Hi Andrew:
>>
>> Sorry for late, but as this solution does not resolve I18N (working
>> aound for 815 only?) , I guess we may have another way.
>> If I understand correctly, this solution try to analysis error  
>> code in
>> native code, throws ErrorCodeException; and java code catch this  
>> exception,
>> get error code, and throw another exception.
>> If so, why not just return the error code directly instead? :)
>>
> Hello Jimmy,
>
> IIRC, It's SocketException that is thrown in native code, not  
> ErrorCodeException. And we will set the ErrorCodeException as cause  
> of the SocketException.

Yes, this is how I remember it too. The idea was to do the equivalent  
of the
following code in the native code (correct me if I'm wrong):

ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException("Some Message", ece);

I don't think it is semantically correct to set the  
ErrorCodeException as the cause
of the SocketException - the error code provides additional info, it  
is not the cause
of the problem. For example, this code:

try {
	ErrorCodeException ece = new ErrorCodeException(13);
	throw new TestException("Something went wrong", ece);
} catch(TestException e) {
	e.printStackTrace();
}

Yields the following stack trace:

net.guglhupf.test.TestException: Something went wrong
	at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
	at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)

which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.

Regards,
David

[1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 
200607.mbox/% 
3c4d0b24970607121958l31cc127y51ff764d58d2b3cd@mail.gmail.com%3e

> I18N is anther issue, we shall have full discussion in community to  
> mature our thoughts. :-)
>
> Do I miss something?
>
> Best regards,
> Richard.
>
>>
>> 2006/7/14, Mikhail Loenko <mloenko@gmail.com>:
>>>
>>> Hi Andrew
>>>
>>> this seems reasonable
>>>
>>> Thanks,
>>> Mikhail
>>>
>>> 2006/7/14, Andrew Zhang <zhanghuangzhu@gmail.com>:
>>> > Hi folks,
>>> >
>>> > I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids
>>> message
>>> > comparison while keeps current luni native architecture.
>>> >
>>> > Before I upload a new patch to JIRA, I want to hear more voices  
>>> from
>>> > the community. Any better suggestions? Any comments?
>>> >
>>> > Mikhail, what's your opnion? Do you think it makes sense?
>>> >
>>> > Thanks in advance!
>>> >
>>> > Best regards,
>>> > Andrew
>>> >
>>> >
>>> > On 7/14/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> > >
>>> > > Andrew Zhang wrote:
>>> > > > How about design a subclass which extends from  
>>> SocketException,
>>> looks
>>> > > like:
>>> > >
>>> > > If you want to preserve the throwable type you could create a
>>> > > o.a.h.luni.ErrorCodeException that has a errorCode field set  
>>> by the
>>> > > native, and then make that the cause of the SocketException.
>>> > >
>>> > > The calling code would then do something like:
>>> > > ((ErrorCodeException)ex.getCause()).getErrorCode()
>>> > >
>>> > > Just a thought.
>>> > >
>>> > > Regards,
>>> > > Tim
>>> > >
>>> > >
>>> > > > class SocketWithErrorCodeException extends SocketException {
>>> > > >
>>> > > > SocketWithErrorCodeException (String message, int errorCode) {
>>> > > > super(message); this.errorCode = errorCode; }
>>> > > >
>>> > > > private int errorCode;
>>> > > >
>>> > > > public void get/setErrorCode() ;
>>> > > >
>>> > > > }
>>> > > >
>>> > > > Native code throws SocketWithErrorCodeException instead of
>>> > > SocketException
>>> > > > so that java code could process different error by invoking
>>> > > e.getErrorCode
>>> > > > ().
>>> > > >
>>> > > > Does that make sense?
>>> > > >
>>> > > > Thanks!
>>> > > >
>>> > > > On 7/13/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>> > > >>
>>> > > >> I agree with the reason why (I think I understand it - you
 
>>> don't
>>> want
>>> > > to
>>> > > >> rely on the result of getMessage() to determine the  
>>> problem...)
>>> > > >>
>>> > > >> Could you wrap the socket exception to carry a simple  
>>> integer error
>>> > > code?
>>> > > >>
>>> > > >> geir
>>> > > >>
>>> > > >>
>>> > > >> Mikhail Loenko wrote:
>>> > > >> > -1 for applying the patch
>>> > > >> >
>>> > > >> > Applying this patch means creating a hidden problem
>>> > > >> >
>>> > > >> > Thanks,
>>> > > >> > Mikhail
>>> > > >> >
>>> > > >> > 2006/7/12, Jimmy, Jing Lv <firepure@gmail.com>:
>>> > > >> >> Andrew Zhang wrote:
>>> > > >> >> > Hello Mikhail,
>>> > > >> >> >
>>> > > >> >> > Please see my comments inline.
>>> > > >> >> >
>>> > > >> >> > Thanks!
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > On 7/12/06, Mikhail Loenko <mloenko@gmail.com>
wrote:
>>> > > >> >> >>
>>> > > >> >> >> 2006/7/12, Andrew Zhang <zhanghuangzhu@gmail.com>:
>>> > > >> >> >> > Hi Mikhail,
>>> > > >> >> >> >
>>> > > >> >> >> > It's a NON-NLS message.
>>> > > >> >> >> >
>>> > > >> >> >> > Native code is designed in this way.
Currently,  
>>> Harmony
>>> socket
>>> > > >> >> native
>>> > > >> >> >> code
>>> > > >> >> >> > uses messages in SocketException to
identify error  
>>> type.
>>> > > >> >> >> >
>>> > > >> >> >> > To avoid the confusion, two alternatives
way I  
>>> could image
>>> are:
>>> > > >> >> >> >
>>> > > >> >> >> > 1. Native code returns platform-independent
error  
>>> code.
>>> > > >> >> >> >
>>> > > >> >> >> > 2. Native code throws different exceptions,
which  
>>> are all
>>> > > >> >> extended from
>>> > > >> >> >> > SocketException.
>>> > > >> >> >> >
>>> > > >> >> >> > Anyway, as current Harmony native design,
the  
>>> message in
>>> > > >> >> >> SocketException
>>> > > >> >> >> > thrown by native code is a NON-NLS
string, that is  
>>> to say,
>>> like
>>> > > >> >> >> "GET","POST"
>>> > > >> >> >> > in http protocol. Unless we take a
big change on  
>>> native
>>> code
>>> > > >> >> design, I
>>> > > >> >> >> > don't think the code is dangerous.
>>> > > >> >> >> >
>>> > > >> >> >> > What's your opnion?
>>> > > >> >> >>
>>> > > >> >> >> I like option #2.
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > I also prefer option1 and 2 to current native
solution.
>>> > > >> >> >
>>> > > >> >> > I don't think exception messages are the same
as  
>>> "GET" and
>>> > > >> "POST", we
>>> > > >> >> > agreed
>>> > > >> >> >> that the messages are to be internationalized.
I see  
>>> that
>>> > > currently
>>> > > >> >> not
>>> > > >> >> >> all
>>> > > >> >> >> the messages are internationalized but I
think they  
>>> will in
>>> the
>>> > > >> >> future.
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > NO. Currently, exception message thrown by native
 
>>> code are
>>> used as
>>> > > >> >> if error
>>> > > >> >> > code [1]. Please pay attention to netLookupErrorString
>>> function.
>>> > > >> >> >
>>> > > >> >> > Harmony-815 patch is based on current Harmony
native
>>> > > implemenation,
>>> > > >> >> > therefore, it should work well if design is
not changed.
>>> > > >> >> >
>>> > > >> >> > If we decide to adopt option 1, or 2, we have
to re- 
>>> design
>>> native
>>> > > >> >> and java
>>> > > >> >> > interface,
>>> > > >> >> >
>>> > > >> >> > and there are lots of native and java code to
be  
>>> changed.
>>> > > >> >> >
>>> > > >> >> > How to design native interface is out of scope
to  
>>> this patch,
>>> > > >> >> therefore, I
>>> > > >> >> > think a seperate JIRA or thread for socket native
 
>>> interface
>>> design
>>> > > >> >> is more
>>> > > >> >> > suitable.
>>> > > >> >> >
>>> > > >> >> > Of course, once decision is made, I'll volunteer
to  
>>> revise
>>> native
>>> > > >> >> and java
>>> > > >> >> > code.
>>> > > >> >> >
>>> > > >> >>
>>> > > >> >> Yep, I also find this strange style of return value,
I  
>>> doubt if
>>> the
>>> > > >> >> exception thrown in native may be an enhancement
to code
>>> efficiency?
>>> > > >> >> However to refactor this may be a heavy work, as
much code
>>> follows
>>> > > >> this
>>> > > >> >> style, affects both luni and nio. I suggest apply
this  
>>> patch,
>>> and
>>> > > >> leave
>>> > > >> >> this work until Harmony begins i18n.
>>> > > >> >>
>>> > > >> >> > Does it make sense?
>>> > > >> >> >
>>> > > >> >> > Thanks!
>>> > > >> >> >
>>> > > >> >> > [1] native-src (nethelp.c)
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > void
>>> > > >> >> > throwJavaNetSocketException (JNIEnv * env, I_32
 
>>> errorNumber)
>>> > > >> >> > {
>>> > > >> >> > jclass aClass;
>>> > > >> >> > /* the error message lookup should be done before
the
>>> FindClass
>>> > > >> call,
>>> > > >> >> > because the FindClass call
>>> > > >> >> > * may reset the error number that is used in
>>> > > hysock_error_message
>>> > > >> */
>>> > > >> >> >
>>> > > >> >> > // !!! Here, error code is mapped to NON-NLS
mesage.
>>> > > >> >> > char *errorMessage = netLookupErrorString (env,
 
>>> errorNumber);
>>> > > >> >> > aClass = (*env)->FindClass (env, "java/net/

>>> SocketException");
>>> > > >> >> > if (0 == aClass)
>>> > > >> >> > {
>>> > > >> >> > return;
>>> > > >> >> > }
>>> > > >> >> > (*env)->ThrowNew (env, aClass, errorMessage);
>>> > > >> >> >
>>> > > >> >> > }
>>> > > >> >> >
>>> > > >> >> > char *
>>> > > >> >> > netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
>>> > > >> >> > {
>>> > > >> >> > PORT_ACCESS_FROM_ENV (env);
>>> > > >> >> > switch (anErrorNum)
>>> > > >> >> > {
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADSOCKET:
>>> > > >> >> > return "Bad socket";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
>>> > > >> >> > return "Socket library uninitialized";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADAF:
>>> > > >> >> > return "Bad address family";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADPROTO:
>>> > > >> >> > return "Bad protocol";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADTYPE:
>>> > > >> >> > return "Bad type";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMBUSY:
>>> > > >> >> > return "System busy handling requests";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMFULL:
>>> > > >> >> > return "Too many sockets allocated";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTCONNECTED:
>>> > > >> >> > return "Socket is not connected";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_INTERRUPTED:
>>> > > >> >> > return "The call was cancelled";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUT:
>>> > > >> >> > return "The operation timed out";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_CONNRESET:
>>> > > >> >> > return "The connection was reset";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_WOULDBLOCK:
>>> > > >> >> > return "The socket is marked as nonblocking
operation
>>> would
>>> > > >> >> block";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_ADDRNOTAVAIL:
>>> > > >> >> > return "The address is not available";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_ADDRINUSE:
>>> > > >> >> > return "The address is already in use";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTBOUND:
>>> > > >> >> > return "The socket is not bound";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNSOCKET:
>>> > > >> >> > return "Resolution of the FileDescriptor to
socket
>>> failed";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_INVALIDTIMEOUT:
>>> > > >> >> > return "The specified timeout is invalid";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSETFULL:
>>> > > >> >> > return "Unable to create an FDSET";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALFULL:
>>> > > >> >> > return "Unable to create a TIMEVAL";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_REMSOCKSHUTDOWN:
>>> > > >> >> > return "The remote socket has shutdown gracefully";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTLISTENING:
>>> > > >> >> > return "Listen() was not invoked prior to accept()";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTSTREAMSOCK:
>>> > > >> >> > return "The socket does not support connection-oriented
>>> > > >> service";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_ALREADYBOUND:
>>> > > >> >> > return "The socket is already bound to an address";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NBWITHLINGER:
>>> > > >> >> > return "The socket is marked non-blocking &
SO_LINGER is
>>> > > >> >> non-zero";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_ISCONNECTED:
>>> > > >> >> > return "The socket is already connected";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOBUFFERS:
>>> > > >> >> > return "No buffer space is available";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_HOSTNOTFOUND:
>>> > > >> >> > return "Authoritative Answer Host not found";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NODATA:
>>> > > >> >> > return "Valid name, no data record of requested
type";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BOUNDORCONN:
>>> > > >> >> > return "The socket has not been bound or is
already
>>> > > connected";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPNOTSUPP:
>>> > > >> >> > return "The socket does not support the operation";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPTUNSUPP:
>>> > > >> >> > return "The socket option is not supported";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPTARGSINVALID:
>>> > > >> >> > return "The socket option arguments are invalid";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_SOCKLEVELINVALID:
>>> > > >> >> > return "The socket level is invalid";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUTFAILURE:
>>> > > >> >> > return "The timeout operation failed";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_SOCKADDRALLOCFAIL:
>>> > > >> >> > return "Failed to allocate address structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSET_SIZEBAD:
>>> > > >> >> > return "The calculated maximum size of the file
>>> descriptor
>>> > > set
>>> > > >> is
>>> > > >> >> > bad";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNFLAG:
>>> > > >> >> > return "The flag is unknown";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_MSGSIZE:
>>> > > >> >> > return
>>> > > >> >> > "The datagram was too big to fit the specified
 
>>> buffer, so
>>> > > >> truncated";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NORECOVERY:
>>> > > >> >> > return "The operation failed with no recovery
possible";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_ARGSINVALID:
>>> > > >> >> > return "The arguments are invalid";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADDESC:
>>> > > >> >> > return "The socket argument is not a valid file
>>> descriptor";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTSOCK:
>>> > > >> >> > return "The socket argument is not a socket";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_HOSTENTALLOCFAIL:
>>> > > >> >> > return "Unable to allocate the hostent structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALALLOCFAIL:
>>> > > >> >> > return "Unable to allocate the timeval structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_LINGERALLOCFAIL:
>>> > > >> >> > return "Unable to allocate the linger structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_IPMREQALLOCFAIL:
>>> > > >> >> > return "Unable to allocate the ipmreq structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSETALLOCFAIL:
>>> > > >> >> > return "Unable to allocate the fdset structure";
>>> > > >> >> > case HYPORT_ERROR_SOCKET_CONNECTION_REFUSED:
>>> > > >> >> > return "Connection refused";
>>> > > >> >> >
>>> > > >> >> > default:
>>> > > >> >> > return (char *) hysock_error_message ();
>>> > > >> >> > }
>>> > > >> >> > }
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > Thanks,
>>> > > >> >> >> Mikhail
>>> > > >> >> >>
>>> > > >> >> >>
>>> > > >> >> >> >
>>> > > >> >> >> > Best regards,
>>> > > >> >> >> > Andrew
>>> > > >> >> >> >
>>> > > >> >> >> >
>>> > > >> >> >> > On 7/11/06, Mikhail Loenko (JIRA) 

>>> <jira@apache.org> wrote:
>>> > > >> >> >> > >
>>> > > >> >> >> > > [
>>> > > >> >> >> > >
>>> > > >> >> >>
>>> > > >> >>
>>> > > >>
>>> > >
>>> http://issues.apache.org/jira/browse/HARMONY-815? 
>>> page=comments#action_12420281
>>> > > >>
>>> > > >> >>
>>> > > >> >> >>
>>> > > >> >> >> ]
>>> > > >> >> >> > >
>>> > > >> >> >> > > Mikhail Loenko commented on HARMONY-815:
>>> > > >> >> >> > > ----------------------------------------
>>> > > >> >> >> > >
>>> > > >> >> >> > > Hi Andrew
>>> > > >> >> >> > >
>>> > > >> >> >> > > I think it's rather dangerous:
>>> > > >> >> >> > >
>>> > > >> >> >> > > } catch (SocketException e) {
>>> > > >> >> >> > > if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage
>>> ()))
>>> > > {
>>> > > >> >> >> > > return sendCount;
>>> > > >> >> >> > > }
>>> > > >> >> >> > > throw e;
>>> > > >> >> >> > >
>>> > > >> >> >> > > Once we internationilize our code
that won't work
>>> > > >> >> >> > >
>>> > > >> >> >> > > > [classlib][nio] Refine implConfigureBlocking

>>> (boolean)
>>> > > method
>>> > > >> of
>>> > > >> >> >> > > DatagramChannel and SocketChannel.
>>> > > >> >> >> > > >
>>> > > >> >> >> > >
>>> > > >> >> >>
>>> > > >> >>
>>> > > >>
>>> > >
>>> -------------------------------------------------------------------- 
>>> ------------------------------
>>> > > >>
>>> > > >> >>
>>> > > >> >> >>
>>> > > >> >> >> > > >
>>> > > >> >> >> > > > Key: HARMONY-815
>>> > > >> >> >> > > > URL:
>>> > > >> http://issues.apache.org/jira/browse/HARMONY-815
>>> > > >> >> >> > > > Project: Harmony
>>> > > >> >> >> > > > Type: Improvement
>>> > > >> >> >> > >
>>> > > >> >> >> > > > Components: Classlib
>>> > > >> >> >> > > > Reporter: Andrew Zhang
>>> > > >> >> >> > > > Assignee: Mikhail Loenko
>>> > > >> >> >> > > > Attachments: nio.diff
>>> > > >> >> >> > > >
>>> > > >> >> >> > > > Currently, Harmony
>>> > > >> >> DatagramChannel.implConfigureBlocking(boolean)
>>> > > >> >> >> does
>>> > > >> >> >> > > nothing.
>>> > > >> >> >> > > > It doesn't cause any problem
of read operation  
>>> because
>>> > > >> >> Harmony uses
>>> > > >> >> >> > > select+blocking read to ensure
nonblocking reading.
>>> > > >> >> >> > > > But it affects write operations,
although it is
>>> difficult
>>> > > to
>>> > > >> >> test
>>> > > >> >> >> the
>>> > > >> >> >> > > difference between blocking write
and blocking  
>>> write.
>>> > > >> >> >> > > > Another defect is introduced
by portlib bug. As
>>> discussed
>>> > > on
>>> > > >> >> >> mailing
>>> > > >> >> >> > > list[1], connect_with_timeout
always changes the  
>>> fd to
>>> > > blocking
>>> > > >> >> mode
>>> > > >> >> >> after
>>> > > >> >> >> > > invocation.
>>> > > >> >> >> > > > I'll upload a patch to fix
these problems.
>>> > > >> >> >> > > > Thanks!
>>> > > >> >> >> > > > Best regards,
>>> > > >> >> >> > > > Andrew
>>> > > >> >> >> > >
>>> > > >> >> >> > > --
>>> > > >> >> >> > > This message is automatically
generated by JIRA.
>>> > > >> >> >> > > -
>>> > > >> >> >> > > If you think it was sent incorrectly
contact one  
>>> of the
>>> > > >> >> >> administrators:
>>> > > >> >> >> > >
>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>> > > >> >> >> > > -
>>> > > >> >> >> > > For more information on JIRA,
see:
>>> > > >> >> >> > > http://www.atlassian.com/software/jira
>>> > > >> >> >> > >
>>> > > >> >> >> > >
>>> > > >> >> >> >
>>> > > >> >> >> >
>>> > > >> >> >> > --
>>> > > >> >> >> > Andrew Zhang
>>> > > >> >> >> > China Software Development Lab, IBM
>>> > > >> >> >> >
>>> > > >> >> >> >
>>> > > >> >> >>
>>> > > >> >> >>
>>> > > >>
>>> -------------------------------------------------------------------- 
>>> -
>>> > > >> >> >> Terms of use :
>>> http://incubator.apache.org/harmony/mailing.html
>>> > > >> >> >> To unsubscribe, e-mail:
>>> > > >> harmony-dev-unsubscribe@incubator.apache.org
>>> > > >> >> >> For additional commands, e-mail:
>>> > > >> harmony-dev-help@incubator.apache.org
>>> > > >> >> >>
>>> > > >> >> >>
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >>
>>> > > >> >>
>>> > > >> >> --
>>> > > >> >>
>>> > > >> >> Best Regards!
>>> > > >> >>
>>> > > >> >> Jimmy, Jing Lv
>>> > > >> >> China Software Development Lab, IBM
>>> > > >> >>
>>> > > >> >>
>>> > >  
>>> -------------------------------------------------------------------- 
>>> -
>>> > > >> >> Terms of use : http://incubator.apache.org/harmony/

>>> mailing.html
>>> > > >> >> To unsubscribe, e-mail:
>>> harmony-dev-unsubscribe@incubator.apache.org
>>> > > >> >> For additional commands, e-mail:
>>> > > harmony-dev-help@incubator.apache.org
>>> > > >> >>
>>> > > >> >>
>>> > > >> >
>>> > > >> >
>>> -------------------------------------------------------------------- 
>>> -
>>> > > >> > Terms of use : http://incubator.apache.org/harmony/ 
>>> mailing.html
>>> > > >> > To unsubscribe, e-mail:
>>> harmony-dev-unsubscribe@incubator.apache.org
>>> > > >> > For additional commands, e-mail:
>>> > > harmony-dev-help@incubator.apache.org
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> > > >>
>>> -------------------------------------------------------------------- 
>>> -
>>> > > >> Terms of use : http://incubator.apache.org/harmony/ 
>>> mailing.html
>>> > > >> To unsubscribe, e-mail:
>>> harmony-dev-unsubscribe@incubator.apache.org
>>> > > >> For additional commands, e-mail:
>>> harmony-dev-help@incubator.apache.org
>>> > > >>
>>> > > >>
>>> > > >
>>> > > >
>>> > >
>>> > > --
>>> > >
>>> > > Tim Ellison (t.p.ellison@gmail.com)
>>> > > IBM Java technology centre, UK.
>>> > >
>>> > >  
>>> -------------------------------------------------------------------- 
>>> -
>>> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> > > To unsubscribe, e-mail: harmony-dev- 
>>> unsubscribe@incubator.apache.org
>>> > > For additional commands, e-mail: harmony-dev- 
>>> help@incubator.apache.org
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> > Andrew Zhang
>>> > China Software Development Lab, IBM
>>> >
>>> >
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev- 
>>> help@incubator.apache.org
>>>
>>>
>>
>>
>
> -- 
> Richard Liang
> China Software Development Lab, IBM
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>


Mime
View raw message